dvd iso playback with storage groups (long loading time)

[kloana@…]

Hi,

with mythtv version 0.24 + fixes from 12.12.2010 on frontend and backend the iso playback starting time is 30sec. up to one minute. All dvd's are unecryted and stored in storage groups. When i brows the videos everything is ok, but when i start to play a video, this takes up to one minute till the first picture is displayed. After that all the dvd playback is working like a charm.

attached you can find the mythfrontend -l logfile. In this log i started to play "Over the hedge - iso DVD" at appr. 13:03:05. First picture came up on 13:03:21 saying "playback starting". And the first DVD-picture came up on 13:03:49. During this time i can see on my Cisco switch traffic which is going up to 60MBit's per second.

Network between frontend and backend is 100MBit full duplex.

If you need additional logs, please contact me.

regards Herbert

[robertm]

This is a known limitation of ISO/Video_TS/BDMV over Storage Groups when many small files are present.

[stuartm]

A known bug is still a bug.

[robertm]

And yet it's not a bug, it's a known limitation.

[robertm]

Stuart would like to address this one, reopening.

[kloana@…]

Which small files? There is only one Iso with all the data inside! I only have one iso,... Where are the small files?

regards Herbert

[robertm]

The ISO if full of tiny IFO, VOB, etc. files. It may appear to be one file to you, but it's a disc image, not a single file.

[kloana@…]

and this appear for each dvd's? Maybe you have a solution, which i can use, to have working iso's. I don't know which but maybe you have one, or do i have to live with that in iso rip's and internal player?

regards Herbert

[markk]

ref #9854

[cpinkham]

I've attached a patch 9437_remote_dvd_speedup_v1.diff that has significantly improved my remote DVD playback startup speed.

The first part of the patch tries to fix an issue where an immediate read after an optimized backwards seek is locked waiting for more data to be read from the backend even though the required data is actually already inside the ringbuffer. Adding this fix cut my remote DVD startup times by 30% or more.

The second part of the patch is only applicable to VIDEO_TS and BDMV directories. This patch tightens the restrictions for using a remote file optimization. In the current code, we use a RemoteFile? object for remote files less than 50KiB in size. In testing, I noticed that the DVD nav code often seeked backwards in the same file and reread the same data. When using a RemoteFile?, we do not have the benefit of a local data cache, so these backwards seeks require re-reading the data from the backend. The patch changes this filesize threshold to 512 bytes so that we use a RingBuffer? (and it's built in cache) for files >= 512 bytes in size. This part of the patch also improved playback startup speed for me for VIDEO_TS and BDMV directories.

The second part of the patch is a trivial change and should not have any negative effects. The first part of the patch regarding optimized backwards seeks has been tested, but is not installed on my production systems currently. Daniel wants to look at this part of the patch further before this could be rolled into master, but I wanted to provide a copy in this ticket so that others could test it if they want to do so.

[markk]

Fixed in:

da49d7999ba1f2cede500dbd78fdb2dbc88adaee and d1537a588ef346e2d581eabd92dc9d24f0c50e09 and e8f6baf050fe97853a1dbbbb44e1d2ca6904fcee