Weird Media Folder Navigation

For help and support with Universal Media Server
Forum rules
Please make sure you follow the Problem Reporting Guidelines before posting if you want a reply
Post Reply
S0me0ne
Posts: 5
Joined: Sun Jan 06, 2013 4:55 am

Weird Media Folder Navigation

Post by S0me0ne »

Hi,
I'm using a Kathrein UFS-922 satellite receiver with some UPnP client capabilities.
For that purpose, I also started to adapt a .conf file, where I e.g. changed CreateDLNATreeFaster = true to ... = false for some tests.

However, the folder navigation inside the shared directory is very weird. Imagine that there are folders like

+ movies (HDD1)
+ + action
+ + comedy
+ + + criminal
+ + + romantic
+ + drama
+ movies2 (HDD2)

i.e. the actual files are in the third level below the top folder.
Now when I open the Universal Media Server (UMS) 'library', I see only 'movies', but not 'movies2'. (I'm not 100% sure if it also happens on top level, but definitely on the next levels).
I need to leave the UMS 'library' and open another UPnP media library (typically the HDD of the satellite receiver itself, or another file share of my PC)
Then I can close that one and re-open UMS. Now I see all entries of the topmost level.
But when I change into 'movies', I only see 'action'.
Again I need to leave UMS, open another server and come back. Now I see 'action', 'comedy' and 'drama'
You guess what happens when I open 'comedy'? I only see 'criminal' here.
So, to open a romantic comedy movie, I have to repeat the procedure twice more to find 'romantic' and not only the first, but all movies of this category.

* CreateDLNATreeFaster seemed not to change the situation
* With PS3 Media Server, it is the same.
User avatar
SubJunk
Lead Developer
Posts: 3707
Joined: Sun May 27, 2012 4:12 pm

Re: Weird Media Folder Navigation

Post by SubJunk »

Thanks for the report. Can you try some older versions and see if it still happens with them?
S0me0ne
Posts: 5
Joined: Sun Jan 06, 2013 4:55 am

Re: Weird Media Folder Navigation

Post by S0me0ne »

My apologies for the delay.

All server versions were ran out of Sandboxie sandboxes. Before installing another version, the sandbox was cleaned. The tests were done in the sequence they are described here. Several versions timed out when they tried to download a JRE. JRE 7u10 was installed manually in these cases. Because the player (client) does not meet any of the patterns of the shipped *.conf files, I expect that it was always served with default settings.
Two behaviours were observed, which I refer to as (a) abd (b). The default server behaviour which shares all drives was not changed before testing with the client. The tested server has multiple drives.

(a) is the behaviour of old versions. Top level behaviour: When the server was entered, it did sometimes show all drives, sometimes only one, sometimes no share at all. May be version dependent, was not further investigated/documented.
Subfolder behaviour: typically no item at all is displayed on first entry into a folder. *It is sufficient to browse up one level and then directly re-enter the level again to display all items of a level*.
(b) is the behaviour of newer versions. I am still a bit unsure about the top level behaviour. I think I remember situations with only one drive and with all drives shown.
Subfolder behaviour: exactly one item is displayed on first entry into a folder. *It is neccessary to leave the server completely and re-open its top level to display all items of a level*.

Virtual # TRANSCODING' and # CHAPTERS # folders are items in their parent folder and affected there. But inside, they are not affected and alyways show all items from the start with (b), not tested with (a).

With (a) and (b), the procedure repeats on every level. I mark an "empty" folder with '[]', a folder that displays its items with '{}'
I.e with drive C:, folders C:\d\e and media files f & g where g is the media file to be streamed
(a) would look like [C:\] - leave the server - {C:\} - [C:\d] - {C:} - {C:\d} - [C:\d\e] - {C:\d} - {C:\d\e} - stream g
(b) would look like [C:\] - leave the server - {C:\} - [C:\d] - {C:} - leave the server - {C:\} - {C:\d} - [C:\d\e] - {C:\d} - {C:} - leave the server - {C:\} - {C:\d} - {C:\d\e} - stream g

Server version | Java | behaviour
UMS 2.2.2 | timeout | (b)
UMS 1.0 | timeout | (b)

PMS 1.72.0 | timeout | (b)
PMS 1.04 | OK, JRE 6 | (a)
PMS 1.30.1 | OK, JRE 6 | (a) - ('java -version' responds 'java version "1.6.0_26"')
PMS 1.51.0 | timeout | (b)
Manual install of JRE 7u10, then PMS 1.30.1 --> (a). Conclusion: (a)/(b) do not depend on JRE.
PMS 1.40.0 | timeout | (b)
PMS 1.31.0-b1 | OK JRE 6 | (b)

PMS 1.30.1 | OK, JRE 6 | (a) --> same as above. This was done to verify that the results are stable and reproduceable.

So the (a)-->(b) transition is between PMS 1.30.1 and PMS 1.31.0-b1.

Unfortunately, there are only two flavours of unwanted behaviour. With any bad luck, my version test only reflects the introduction of the 'CreateDLNATreeFaster' switch. Although this switch does not affect the server behaviour of UMS 2.2.2, where I tailored a .conf file for the client.

I can offer to log the network communication with WireShark, but I need some advice on filtering and all that.
Post Reply