DLNA and external subtitles

[kxzaon]

I'm testing the DLNA server that seems to be too good to be true but I have a small issue with this DLNA server. It doesn't seem to recognize my external subtitles. On your website, at the DLNA page, I can read :"Rclone will list all files present in the remote, without filtering based on media formats or file extensions. Additionally, there is no media transcoding support. This means that some players might show files that they are not able to play back correctly." However, in my debug log, I can see :

2019/10/04 01:50:32 DEBUG : DLNA server on :7879: unrecognized file type: **************.srt

I can provide more log if you want. Is there a way to have external subtitles working ? The synology DLNA server can see these files and sends them to my LG WebOS player, it is working perfectly.

Thanks for your time.

[ncw]

Hmm, I think this is because the mime type of .srt files doesn't match

https://github.com/rclone/rclone/blob/d15425e8c8356524ab7c624b5173abaa07a6e077/cmd/serve/dlna/cds.go#L68

which means that this returns nil, nil

https://github.com/rclone/rclone/blob/d15425e8c8356524ab7c624b5173abaa07a6e077/cmd/serve/dlna/cds.go#L106-L109

which in turn means this skips the file and emits the debug

https://github.com/rclone/rclone/blob/d15425e8c8356524ab7c624b5173abaa07a6e077/cmd/serve/dlna/cds.go#L166-L174

I'm not sure of the consequence of widening that check though - @sretlawd what do you think?

[ghost]

Yeah, external SRTs is actually a bit of a pet project of mine ... :-) Unfortunately it's not as simple as just listing the SRT file like any other, the subtitles have to be explicitly associated with the media file in the XML metadata.

I have a branch that serves external SRTs with the "modern method", it works with VLC and on my LG webOS 2 TV. I've been trying to get it to work on my Samsung F series before submitting it, but I've spent untold hours on it and still havn't figured that one out. It's possible that it may work on newer Samsungs though.

I'll rebase and send up what I have here in a sec, though.

[ncw]

I've merged that to master now which means it will be in the latest beta in 15-30 mins and released in v1.50

Thanks @sretlawd :-)

Can you give it a go @kxzaon

[kxzaon]

I've tested it out this morning from 3 differents systems and the latest beta continues to give me this error when I try to connect my client (LG WebOS and VLC also) : /ctl: 192.168.1.21:54672 POST 500 "urn:schemas-upnp-org:service:ContentDirectory:1#Browse" runtime error: index out of range [2] with length 2

When I retry with 1.49.3, the DLNA server works again but obviously without subtitles. It seems like we have problem with DLNA service with this merge.

PS : My debug log prints that *.srt are now supported on the other hand.

[ghost]

Looks like the search logic fails with subdirectories. I'll send a patch up tonight.

[ghost]

Subdirectories seem fine, so not sure what it was exactly, but some combination of srt and media filenames in your remote caused the search logic to fail. I didn't manage to reproduce it. Anyway, there were definitely a couple other problems that I did find, so I just simplified the search logic.

[kxzaon]

I've tested your "dlna_subtitle_search_fix" branch minutes ago, and it doesn't work well in my case. My DLNA clients (LG WebOS or VLC) refuse to connect until a full scan of the video files folder has been complete. During this scan, .srt seems to be well recognized and associated to the video file and other filetypes are unrecognized as wanted (.nfo for example). So far it seems to work fine even if it takes hours to scan a folder full of video files. But even without errors in the debug log, my video player refuse to take in count the srt associated. I don't know what's wrong.

[ghost]

Definitely has to list the whole directory (but just the filenames, not file contents) - not too much that can be done about that. Assume you're using a cloud storage remote? I still only use local storage myself and havn't even tried locally with a large number of files, but from what I understand it should be caching the directory listing...

[kxzaon]

Alright but it definitely didn't act like that before the external subtitles fix. It scans only files that isn't movie. That's why it seems that this is an issue.

[ghost]

Hmm, I’d expect it to be roughly the same speed as the latest released rclone version (but not master, since that’s erring out early for you..). Looks like the sort order was off, which could be a problem in combination w/ pagination. Other than that nothing jumps out at me as materially impacting performance… I take it this is a really big directory listing?

On Oct 7, 2019, at 2:27 PM, kxzaon notifications@github.com wrote:

Alright but it definitely didn't act like that before the external subtitles fix. It scans only files that isn't movie. That's why it seems that this is an issue.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rclone/rclone/issues/3588?email_source=notifications&email_token=ACB6DSTL7TU2X6YD3SJ3K53QNOETTA5CNFSM4I5JSCA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEARQQBI#issuecomment-539166725, or mute the thread https://github.com/notifications/unsubscribe-auth/ACB6DSV567JZEFSA42OJVVTQNOETTANCNFSM4I5JSCAQ.

[kxzaon]

About 400 subdirectories which contains one videofile and one external subtitle.

[ghost]

OK, so I generated some fake data structured like you described and tried to access it w/ VLC, and yeah it’s definitely slow. It seems to be VLC’s choice - once you click on the uPNP directory it decides to recursively request the whole directory tree and DLNA metadata over HTTP, and with subtitles working and one subtitle per video, there are now basically twice as many files for it to request.

I’ll play with a couple other implementations and see if there’s anything we could do different, but it’s definitely a “large directory” issue not really due to subtitles. If other implementations don’t behave like that, it’s probably something we could address. If I were to make a wild guess, we don’t currently supply timestamp info in the xml metadata, so maybe the player decides to just issue requests to get those timestamps via HTTP...

On Oct 7, 2019, at 4:32 PM, kxzaon notifications@github.com wrote:

About 400 subdirectories which contains one videofile and one external subtitle.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rclone/rclone/issues/3588?email_source=notifications&email_token=ACB6DSUSH7VLERBYXRP3WZDQNOTHVA5CNFSM4I5JSCA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAR35YA#issuecomment-539213536, or mute the thread https://github.com/notifications/unsubscribe-auth/ACB6DSUWGMYEJ4GEFHGWW7DQNOTHVANCNFSM4I5JSCAQ.

[ncw]

I have merged #3600 as it seems to improve the situation :-)

OK, so I generated some fake data structured like you described and tried to access it w/ VLC, and yeah it’s definitely slow. It seems to be VLC’s choice - once you click on the uPNP directory it decides to recursively request the whole directory tree and DLNA metadata over HTTP, and with subtitles working and one subtitle per video, there are now basically twice as many files for it to request. I’ll play with a couple other implementations and see if there’s anything we could do different, but it’s definitely a “large directory” issue not really due to subtitles.

It might be worth a look at VLC's source to see what it is really doing/expecting at this point...

[ghost]

So, both of my TVs seem to handle the large directory structure w/o any issues, and I’m seeing the same thing happen with VLC against Universal Media Server. Minidlna doesn’t even want to start up w/ that many directories. I’m inclined to just call it a UI issue in VLC (at least on macOS.) It’s the behavior described in the ticket at https://trac.videolan.org/vlc/ticket/20407 https://trac.videolan.org/vlc/ticket/20407 , except I would add it actually starts requesting every single file before getting to and starting to play the very last one...

On Oct 8, 2019, at 1:51 AM, Nick Craig-Wood notifications@github.com wrote:

I have merged #3600 https://github.com/rclone/rclone/pull/3600 as it seems to improve the situation :-)

OK, so I generated some fake data structured like you described and tried to access it w/ VLC, and yeah it’s definitely slow. It seems to be VLC’s choice - once you click on the uPNP directory it decides to recursively request the whole directory tree and DLNA metadata over HTTP, and with subtitles working and one subtitle per video, there are now basically twice as many files for it to request. I’ll play with a couple other implementations and see if there’s anything we could do different, but it’s definitely a “large directory” issue not really due to subtitles.

It might be worth a look at VLC's source to see what it is really doing/expecting at this point...

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rclone/rclone/issues/3588?email_source=notifications&email_token=ACB6DSRQ2ZTLJARRQYLI4Z3QNQUYVA5CNFSM4I5JSCA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEATBR4I#issuecomment-539367665, or mute the thread https://github.com/notifications/unsubscribe-auth/ACB6DSWEHSGSHOQCWXYOWMTQNQUYVANCNFSM4I5JSCAQ.

[kxzaon]

With the last master build, my large library is still fully scanned so it takes ages before playing something. It's clearly a regression from the 1.49.4 build where DLNA content is displayed immediately, but yeah without external subtitles. But indeed, the sort of folders, alphabetically, is back with master build. And I figure it out that only subtitles which are in a folder with a videofile only are played. If there is a .nfo inside the folder for instance, the .srt won't be read. That's why I thinked that your fix didn't work, that's because just a few folders in my library contain only a videofile and a subtitle file. IMO, it is not only a problem with VLC as my LG WebOS behaves the same. It should only scan subdirectory for external files when I want to check this one in particular. And it should search for *.srt and ignore other filetypes. I just give my thoughts. Thanks a lot for your hard work on this.

[ghost]

No worries, like I said, subtitles are a pet project - the .nfo thing is interesting, I’ll look into that. One of my TVs is LG webOS 2 and it seems to work great w/ the large directory, what version is yours?

On Oct 8, 2019, at 12:22 PM, kxzaon notifications@github.com wrote:

With the last master build, my large library is still fully scanned so it takes ages before playing something. It's clearly a regression from the 1.49.4 build where DLNA content is displayed immediately, but yeah without external subtitles. But indeed, the sort of folders, alphabetically, is back with master build. And I figure it out that only subtitles which are in a folder with a videofile only are played. If there is a .nfo inside the folder for instance, the .srt won't be read. That's why I thinked that your fix didn't work, that's because just a few folders in my library contain only a videofile and a subtitle file. IMO, it is not only a problem with VLC as my LG WebOS behaves the same. It should only scan subdirectory for external files when I want to check this one in particular. And it should search for *.srt and ignore other filetypes. I just give my thoughts. Thanks a lot for your hard work on this.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rclone/rclone/issues/3588?email_source=notifications&email_token=ACB6DSWNDNOP5HQ3N6HRJ33QNS6VRA5CNFSM4I5JSCA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAU6J2Y#issuecomment-539616491, or mute the thread https://github.com/notifications/unsubscribe-auth/ACB6DSS53TV3DG2GFVRFKETQNS6VRANCNFSM4I5JSCAQ.

[kxzaon]

I checked your last commit. Congrats, my external subtitles are now played everytime I open a videofile. As DLNA client, mine is LG WebOS 4. Like I said It seems like we have a problem with the search fonction of external files. It gives me exactly the same result that VLC, it scans for everything before offering the listing of subfolders. Don't you think it should be searching for external files only when I enter in a subfolder?

[ghost]

My LG is in Spanish, but roughly translating I get:

Settings > General > About This TV > Software Version == 4.26.0 Settings > General > About This TV > TV Information > WebOS TV Version = 2.23.1351 (beehive-biscayne)

So just to confirm since it’s kinda confusing, your webOS version is reported as 4.x?

Totally, there shouldn’t be any browse activity until you actually enter a subfolder in the UI. My home TVs (Samsung F series & LG webOS 2) never browse a subfolder until you enter it.

I looked over the VLC code a bit and best I can tell it simply won’t scale to large directory trees. In particular, it looks like it will always recursively request every file in the remote. If you know of a server that behaves differently w/ a VLC client then I’m happy to take a look, maybe just email me a Wireshark .pcap if you don’t want to post filenames publicly?

On Oct 8, 2019, at 8:04 PM, kxzaon notifications@github.com wrote:

I checked your last commit. Congrats, my external subtitles are now played everytime I open a videofile. As DLNA client, mine is LG WebOS 4. Like I said It seems like we have a problem with the search fonction of external files. It gives me exactly the same result that VLC, it scans for everything before offering the listing of subfolders. Don't you think it should be searching for external files only when I enter in a subfolder?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rclone/rclone/issues/3588?email_source=notifications&email_token=ACB6DSTMC6ISZXR6WYKD7ETQNUU2FA5CNFSM4I5JSCA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAWEFYY#issuecomment-539771619, or mute the thread https://github.com/notifications/unsubscribe-auth/ACB6DSRJW3ZCXVBT7QRSCY3QNUU2FANCNFSM4I5JSCAQ.

[kxzaon]

Software Version 05.10.10 WebOS version 4.1.3-5523 I will test my synology DLNA server on the same library and I'll update my comment. EDIT: I think Synology DLNA server had to scan the entire library also to be able to give a listing. With rclone serve dlna, I maybe forgot to say that the scan of the library happens only when I launch the server.

[disconnect5852]

Not works with samsung F5300 :( no external subtitles, only internal.

[ghost]

Samsung uses a different technique. I’ve implemented it but haven’t had any luck getting it working. Until I get a serial cable soldered to see some debug log messages on the TV, I’m out of ideas. Will get around to it eventually, though.

On Dec 19, 2019, at 11:11 PM, disconnect5852 notifications@github.com wrote:

Not works with samsung F5300 :( no external subtitles, only internal.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rclone/rclone/issues/3588?email_source=notifications&email_token=ACB6DSVNQ5NWXLIKPDMV7U3QZPPQ7A5CNFSM4I5JSCA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHLBNMA#issuecomment-567678640, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACB6DSW7FLSWN6ND76UNZETQZPPQ7ANCNFSM4I5JSCAQ.

[jorams]

Since this issue seems to be about both the inclusion of external subtitles and the full library scan:

The scan for external subtitles causes a full scan of the remote before any response is returned to the client. This full scan takes a long time, which results in a very rough experience.

My remotes are set up as follows:

union -> crypt -> drive
      \-> local directory

The union contains almost 11 000 files, spread over some 1200 directories, up to 5 levels deep. Some 70% of those files are music, and those are all on local disk. This is what happens:

1. I run rclone serve dlna union: with some additional flags to control caching.
2. It starts up fine, my LG WebOS TV detects the server and requests /rootDesc.xml.
3. I select the server on my TV, and it sends a request for BrowseDirectChildren
4. rclone starts scanning the directory. It combs through everything quite slowly. While this is happening nothing is returned to the TV, and it eventually times out.
5. If I now select the server again, my TV sends a new request for BrowseDirectChildren. This request sees the cached part of the tree. I'm not sure if it then triggers a second full scan for the remaining part of the tree, or if it's just reporting on the results as they arrive from the first one, but every unrecognized file type is now reported twice.
6. Once the scan completes, my TV displays the top-level directory, while (sometimes, not always) simultaneously requesting the contents of subdirectories. This appears to be a prefetch thing, because the UI is perfectly responsive.

I think it might be a good idea to delay the detection of external subtitles until a video file has been detected, and to then scan the subdirectories of the directory it was found in.

[jorams]

I did some further research, and it appears the full scan is not caused by the detection of external subtitles, but by the calculation of childCount (#3541). cdsObjectToUpnpavObject calls readContainer, which calls cdsObjectToUpnpavObject again, and they recurse through the entire tree.

[ghost]

Yeah, that makes sense, not really subtitle related - The original problem was we were sending a child count of 0 even when there were children just because of how Go XML marshaling works. Can definitely make sure we don’t recurse in the process of getting that info, but it's tempting to just omit the child count entirely when that's not already in the cache, and see if any clients are adversely impacted.

On Feb 17, 2020, at 6:03 PM, Joram Schrijver notifications@github.com wrote:

I did some further research, and it appears the full scan is not caused by the detection of external subtitles, but by the calculation of childCount (#3541 https://github.com/rclone/rclone/pull/3541). cdsObjectToUpnpavObject https://github.com/rclone/rclone/blob/219bd97e8ae793cddf0dc1d157460e0eb24c8709/cmd/serve/dlna/cds.go#L72 calls readContainer https://github.com/rclone/rclone/blob/219bd97e8ae793cddf0dc1d157460e0eb24c8709/cmd/serve/dlna/cds.go#L148, which calls cdsObjectToUpnpavObject https://github.com/rclone/rclone/blob/219bd97e8ae793cddf0dc1d157460e0eb24c8709/cmd/serve/dlna/cds.go#L72 again, and they recurse through the entire tree.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rclone/rclone/issues/3588?email_source=notifications&email_token=ACB6DSWLLTEVYEPFENMELT3RDMJUBA5CNFSM4I5JSCA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL73XCY#issuecomment-587185035, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACB6DSUEMT4GGIX6AXHRWN3RDMJUBANCNFSM4I5JSCAQ.

[jorams]

That would definitely be the right solution for me, at least. Just getting rid of the recursion still results in very bad performance on large directories, because every subdirectory needs to be read during navigation.

This media server (that I've never heard of before) makes it optional (Skip Child Count).

[ghost]

It’s definitely optional in the specs I found, but every other server I looked at fills it in .. Of course, most every other server I’ve seen scans the entire media library into a database first, so there’s no cost to do so. I’ll push something up here in a sec.

On Feb 17, 2020, at 6:42 PM, Joram Schrijver notifications@github.com wrote:

That would definitely be the right solution for me, at least. Just getting rid of the recursion still results in very bad performance on large directories, because every subdirectory needs to be read during navigation.

This media server https://wiki.jriver.com/index.php/UPnP_Server_and_Devices_(Media_Receivers) (that I've never heard of before) makes it optional (Skip Child Count).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rclone/rclone/issues/3588?email_source=notifications&email_token=ACB6DSVFO56GSBXAY42XKMDRDMOHJA5CNFSM4I5JSCA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMAAZ3Y#issuecomment-587205871, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACB6DSVGONUVT5CDQKLWKH3RDMOHJANCNFSM4I5JSCAQ.