Problem with downloading one file

Asked by Bartek

Hello again :)

I've stange problem with one of clients that tries to download file nessessary to display playlist:

Outside view in library folder:
-----------------

Until size on disk < expected size => file downloading goes correcty in 500 chunks.

After that => file keeps groving in random chunks without any upper limit.

Log view:
------------
[...]
Get File Completed
Getting the file : 465.mpg chunk : 299008000
Get File Completed
Getting the file : 465.mpg chunk : 299520000
Get File Completed
Getting the file : 465.mpg chunk : 300032000
Get File Completed
Getting the file : 465.mpg chunk : 300544000
Get File Completed
Comparing MD5 of completed download [7e2d3fbb787882b8994c58604910abb6] with given MD5 [7e2d3fbb787882b8994c58604910abb6]
Info: <message>Adding new MD5 to CacheManager</message><method>Add</method>
Media file changed
File downloaded: 465.mpg
Getting the file : 465.mpg chunk : 0
Get File Completed
Getting the file : 465.mpg chunk : 512000
Get File Completed
Getting the file : 465.mpg chunk : 1024000

[...]

So its probably some bug in code :)
Anyway, missed me? ;)

Question information

Language:
English Edit question
Status:
Solved
For:
Xibo Edit question
Assignee:
No assignee Edit question
Solved by:
Bartek
Solved:
Last query:
Last reply:
Revision history for this message
Bartek (czajka) said :
#1

And probably one more important fragment, just when download is started:
Info: <message>Client Started</message><method>Main</method>
HardwareKey: [IN]
HardwareKey: [OUT]
SetGlobalProxy: [IN]
SetGlobalProxy: Trying to detect a proxy.
SetGlobalProxy: No Proxy.
SetGlobalProxy: [OUT]
Info: <message>User AppData Path: C:\Documents and Settings\Default User\Dane aplikacji\Xibo\Xibo Digital Signage\2.0.0.0</me
HardwareKey: [IN]
HardwareKey: [OUT]
Schedule - InitializeComponents: Collection Interval: 180
MainForm - ScheduleChangeEvent: Schedule Changing to C:\Documents and Settings\Default User\Moje dokumenty\Xibo Library\150.x
MainForm - DestoryLayout: Destroying Layout
Schedule - RequiredFilesCompleted: RequiredFilesAsync complete.
HardwareKey: [IN]
HardwareKey: [OUT]
Comparing current MD5 [b45c391e0f1679a32f23a0f705cebfd9] with given MD5 [b45c391e0f1679a32f23a0f705cebfd9]
[...]
Comparing current MD5 [f3481d7fbd2a4b16093992e5bbfaf548] with given MD5 [f3481d7fbd2a4b16093992e5bbfaf548]
Info: <message>File has been written to since cache, recalculating</message><method>GetMD5</method>
Info: <message>Removing stale MD5 from the CacheManager</message><method>Remove</method>
Info: <message>Adding new MD5 to CacheManager</message><method>Add</method>
Comparing current MD5 [23a367c951c2f97bc830724e1e8529be] with given MD5 [7e2d3fbb787882b8994c58604910abb6]
Info: <message>Removing stale MD5 from the CacheManager</message><method>Remove</method>
HardwareKey: [IN]
HardwareKey: [OUT]
There are 4 files to get
Getting the file : 465.mpg chunk : 0
Info: <message>About to Write the Cache Manager</message><method>CacheManager - WriteCacheManager</method>
Get File Completed
Getting the file : 465.mpg chunk : 512000
Get File Completed
Getting the file : 465.mpg chunk : 1024000
Get File Completed
Getting the file : 465.mpg chunk : 1536000
Get File Completed
Getting the file : 465.mpg chunk : 2048000

Revision history for this message
Bartek (czajka) said :
#2

I was womdering if it is correct than requiredFiles() in 1.0.x return same file multiple times?
I've dumped server's responense for this function and 465.mpg is mentioned three times there. maybe becouse of that client tries to download it two times in a row? There is no such information in a wiki.

Revision history for this message
Alex Harrington (alexharrington) said :
#3

I've noticed that too and I think I've mentioned it in passing to Dan.

As far as I'm aware it shouldn't return multiples but I don't know enough
detail about the windows client to know if that will cause it a problem.

Alex

Bartek <email address hidden> wrote:

Question #111392 on Xibo changed:
https://answers.launchpad.net/xibo/+question/111392

Bartek posted a new comment:
I was womdering if it is correct than requiredFiles() in 1.0.x return same
file multiple times?
I've dumped server's responense for this function and 465.mpg is mentioned
three times there. maybe becouse of that client tries to download it two
times in a row? There is no such information in a wiki.

--
You received this question notification because you are a member of Xibo
Developers, which is an answer contact for Xibo.

This email carries a disclaimer, a copy of which may be read at http://learning.longhill.org.uk/disclaimer

Revision history for this message
Bartek (czajka) said :
#4

Interesting, i'm running now something about 95 clients and never got situation like that.

Tried all known client 'reset' methods, different that removing whole libraty - removed xlfs, removed cache_manager, removed broken file etc. Same effect - file started from begining, completed, then growing in 500 chunks from it's correct size to inf ;)

For now i've downladed this file by changing layout to temporary one with this file only, then was correctly downloaded. Next switched back to desired layout, and it's started ok.

Anyway, there is required files xml piece for layout that caused problem, if You want check something:
http://czajkowski.net/~czajka/xibofiles
20 other clients duplicated from same hd downloaded missing file without problems.

Revision history for this message
Dan Garner (dangarner) said :
#5

I remember Alex mentioning this to be some time ago - this will cause the
windows client to download the file again every time it is in required
files.

It is probably because that file features on more than one layout (or is
linked to more than one).

Needless to say RequiredFiles should never return the same file (or layout)
more than once.

I'll look into it (I don't have access to Launchpad from here, can someone
create a bug out of this and target to 1.2.0-rc1?)

Revision history for this message
Bartek (czajka) said :
#6

Hi,

I was thinking about some quick dirty and minimal workaroud for this problem, and there is my fast idea:

   //Add the file node
                        $file = $requiredFilesXml->createElement("file");

                        $file->setAttribute("type", "media");
                        $file->setAttribute("path", $storedAs);
                        $file->setAttribute("id", $mediaId);
                        $file->setAttribute("size", $fileSize);
                        $file->setAttribute("md5", $md5);

                        $fileElements->appendChild($file);

replace with:

                        //Add the file node
                        $file = $requiredFilesXml->createElement("file");

                        $file->setAttribute("type", "media");
                        $file->setAttribute("path", $storedAs);
                        $file->setAttribute("id", $mediaId);
                        $file->setAttribute("size", $fileSize);
                        $file->setAttribute("md5", $md5);

   if(!$idPresent[$mediaId])
    {
                         $fileElements->appendChild($file);
    $idPresent[$mediaId]=1;
    }

It should stop xmds duplicating file entries, right? Of course it could be better, like optimizing sql query or some bigger code inside if statement, but my goal is to make modification as simple as possible.

Revision history for this message
Alex Harrington (alexharrington) said :
#7

Hi Bartek

Last time I spoke to Dan he thought it would be a one line fix - by adding a "DISTINCT" to one of the queries.

It's on his list for 1.1.1 or 1.2.0rc1 so there won't be long to wait for a proper fix.

Alex

Revision history for this message
Bartek (czajka) said :
#8

Sorry for bothering, but until code is contructed like:

for each scheduled layout considered as needed to prepare for
    for each region in layout
        for each element in region
               put element on list;
    put bg on list
    put xlf on list

i think (maybe i'm wrong?) there is no good method for filtering duplicated elements other way that building list of already passed elements?

Each file could be duplicated between layouts, between region,

If there is something like
LayoutA [ Region A1 (....) Region A2 (....) ... ]
LayoutB [ Region B1 (...) Region B2 (....) ...]
...

What if file is used in region A1 & B2? Some DISTINCT could help here?

Revision history for this message
Alex Harrington (alexharrington) said :
#9

It's just an SQL query that generates a list of media items from the
schedule.

All that needs to happen is for the query to be adjusted to return each
media item only once.

Alex

Bartek <email address hidden> wrote:

Question #111392 on Xibo changed:
https://answers.launchpad.net/xibo/+question/111392

    Status: Answered => Open

Bartek is still having a problem:
Sorry for bothering, but until code is contructed like:

for each scheduled layout considered as needed to prepare for
    for each region in layout
        for each element in region
               put element on list;
    put bg on list
    put xlf on list

i think (maybe i'm wrong?) there is no good method for filtering
duplicated elements other way that building list of already passed
elements?

Each file could be duplicated between layouts, between region,

If there is something like
LayoutA [ Region A1 (....) Region A2 (....) ... ]
LayoutB [ Region B1 (...) Region B2 (....) ...]
...

What if file is used in region A1 & B2? Some DISTINCT could help here?

--
You received this question notification because you are a member of Xibo
Developers, which is an answer contact for Xibo.

This email carries a disclaimer, a copy of which may be read at http://learning.longhill.org.uk/disclaimer

Revision history for this message
Bartek (czajka) said :
#10

But there are two queries right now:

SELECT required layouts once
for each selected layout SELECT required elements.

so DISTINCT won't prevent duplicating files between layouts. It's probably less danger that duplicating files inside single layout but still could cause problems in future if client code won't be aware about possible duplications like current windows client.

Anyway my dirty fix helped in my installation so i think it's all in that subject for me, thanks for discussion :)