Problem with ums-6.7.0

[boss]

I'm not sure that it is a particular file which is causing the problem.
If we consider one of the problem folders which is:
/home/media_mnt/Images/Photos/Brians Old Photos/Cars & Bikes

That folder has 130 photos in it.
When I access the folder, I get the "network error" before the contents of the folder is shown.
If I remove just 1 photo from that folder (It can be any of the photos), I can access the folder and all works fine.

Considering that, it seems like the issue is not due to any specific photo but something else.
Your thoughts?

[Nadahar]

I didn't understand it as if it were a particular image, I just needed to know how to identify one of those that didn't work. The path you gave will suffice, it's just to lead me to the right part of the log file.

[Nadahar]

I've studied your logfile a bit, and from what I can see there's multiple issues here. Since it works if you remove an image, they can't all be causing the experienced problem though.

What your LG does that is a bit unusual (as far as I know), is that when browsing a folder it requests only 10 entries at a time. In this case, it was 130 images in this folder (according to UMS at least), so the LG requests 0-9, 10-19, 20-29, 30-39, 40-49, 50-59, 60-69, 70-79, 80-89, 90-99, 100-109, 110-119, 120-129 but it then continue to request 130-139. I think this is where something goes wrong, as UMS replies to that request with 0 results (and it should be one AFAICS).

My guess it therefore that you only experience the problem if the number of media files in the folder is dividable to 10. Could you veryify that? If that's the case, it would be nice if you could make a test folder with a lower number with the same problem (10, 20 or 30 - the lowest that trigger the bug). I'll have to track each image manually to see exactly what goes wrong, so it would be nice not to have to deal with 130 images.

The problem that seems to make your renderer disconnect is another one. Your renderer requests to receive only the first 16 bytes of the first image in the folder. UMS responds by sending the complete image (which is very much more than the expected 16 bytes). We use the "range" parameter for streaming media (audio, video), but I don't think it's implemented for images - which is likely the cause for that problem. The thing is that I can't quite understand why this should be related to the number of images, I'd think that would happen in any case. After rejecting the full image when asking for only 16 bytes, your renderer makes a second request where it requests and receives the full image, so it seems like it handles that - even though UMS doesn't behave properly.

Although both bugs should be addressed, I don't think the two are related and I think it's most likely that it's the first issue that makes your renderer not show any content in the folder.

[boss]

You are correct about the problem being when the number is dividable by 10.
The problem only happens when there is more than 100 images in a folder.
10, 20, 30, 40, 50, 60, 70, 80, 90, 100 images in the folder and there is no problem.
110 images in the folder and the "Network Error" happens
111,112,113 images in the folder and no problem.
120 images in the folder and the "Network Error" happens
121, 122, 123 images in the folder and no problem.
130 images in the folder and the "Network Error" happens
131, 132, 133 images in the folder and no problem.

I also created a new folder and copied 160 random photos to the folder.
When I tried to access that folder, the "Network Error" happened.
I then copied 1 more photo to the folder so there were 161 photos in the folder and all worked OK.

The dividable by 10 (once over 100 photos) definitely seems to be a problem.

Thanks for your ongoing support.

[Nadahar]

I've found a setting that manipulates the "TotalMatches" value returned, "CreateDLNATreeFaster". I can't see your modified renderer configuration anywhere (sorry if I missed it), but does it contain this setting?

[boss]

I'm using the default LG-BP550 configuration file now as it started working OK (for some other issues) since a few versions ago.
The "CreateDLNATreeFaster" setting is not in the default configuration file nor is it in my modified configuration file.

I added the setting "CreateDLNATreeFaster = true" into the default LG-BP550 configuration file and my modified LG-BP550 configuration file and tested with both configuration files.
It didn't resolve the dividable by 10 problem using either of the configuration files.
I also tried it in a few different versions of ums.

[Nadahar]

I think I've fixed the byte range request for images that probably isn't causing the problem but was causing a logged exception. I've added temporary extra logging to all variables related to the total number of items to make it easier for me to follow what's happening, so I'd appreciate a new log file when browsing a 110 images folder: http://superbum.org/downloads/update_totalcount.zip

This "update.jar" should work with the latest Linux test version I uploaded.

[boss]

I copied the update.jar file to the ums folder and created a debug log which is attached.
The error still happens as you said it would.
EDIT: After I posted the debug log, I realised it had 130 images and you asked for 110.
If you want me to do another debug with 110 images please let me know.

Thanks

[Nadahar]

Thank you - 130 will do, I'm just being lazy

[Nadahar]

I can't find much wrong with the file counters except that "TotalMatches" returns 0 instead of 130 when your renderer makes a request with an invalid index. Your renderer asks for 10 at a time as I said, and the problem probably arise because your renderer keeps asking for more media after the 130 items has been sent (the start index is 130, the last valid index is 129 when there are 130 items since "0" is the first). UMS correctly replies with 0 media, but since it doesn't find any it also reports that "TotalMatches" for that folder is 0 (it has with how UMS makes the query internally). I've corrected that so that is should still return the relevant number for "TotalMatches" even if the startindex is out of bounds. Hopefully that will resolve the problem, even though I must say that the LG has a strange way to do this if it uses that number in that case. In any case, here is the latest test: http://superbum.org/downloads/update.jar