Some videos take a very very long time to load

Dev Community Apps & Creations
1

I've found that recently, some videos (seems to be certain movies) take a very very long time to load (I'm talking a few minutes). Once they start playing, they're absolutely perfect, but for some reason they just take forever to start playing.

 

So far it's happened with:

 

1080p movie (.mkv, 1080p, DTS 5.1, subtitles, 10.3GB)

720p movie (.mkv, 720p, DTS 5.1, no subs, 4.5GB)

 

but other movies with similar setups are fine:

 

1080p movie (.mkv, 1080p, DTS 5.1, no subs, 8.3GB)

1080p movie (.mkv, DTS 5.1, no subs, 12.4GB)

 

Looking at the "info" on PMS, there's no discernable difference between the ones that don't work and the ones that do. Anyone else had this recently, and is this a known issue?

 

Rasplex version: 0.4.1 (clean install)

PMS version: 0.9.9.14.531-7eef8c6 on unRaid

 

EDIT: I just compared the media info XMLs and the only difference I see between them is that the two non-working ones have a *lot* of subtitles listed (and both have at least one where the language is ????). However I don't see why that would affect it as I'm telling it to play with subtitles as None

 

 

2

Much more interesting is the video codec embedded in the mkv.

You see, mkv is just a container which can hold many different audio and video codecs. Altough all movies share the same file extension, they could be quite different inside. The speed difference you are experiencing is most likely rooted in differences in the video codec.

For instance it might be, that the 'slow video' uses VC-1 as video codec, which your Pi probably cannot decode natively. So it is transcoded beforehand by plex, which of course is slower.

Second possibility is the use of 10 bit color depth in the h.264 video codec, which many devices cannot decode natively. Or a higher h.264 level (above 4.1 most likely) and with that a high number of ref frames which do require a big amount of RAM for the decoder.

so please compare:

- type of video codec

if all share the h.264 codec, look further and compare

- h.264 level

- # of ref frames

- Bit Depth=10 ?

- anamorphic 1 or 0

- Scan type: progressive or interlaced?

Do also look out if any of the various video, audio and subtitle tracks are accompanied by the words 'zlib' or 'header stripping'.

Update: plex's xml does not tell this, use mediainfo instead.

3

Try this:

http://www.matroska.org/downloads/mkclean.html

/T

4

It can solve problems for older devices. But only a minority of the probs I listed above.

5

Much more interesting is the video codec embedded in the mkv.

You see, mkv is just a container which can hold many different audio and video codecs. Altough all movies share the same file extension, they could be quite different inside. The speed difference you are experiencing is most likely rooted in differences in the video codec.

For instance it might be, that the 'slow video' uses VC-1 as video codec, which your Pi probably cannot decode natively. So it is transcoded beforehand by plex, which of course is slower.

Second possibility is the use of 10 bit color depth in the h.264 video codec, which many devices cannot decode natively. Or a higher h.264 level (above 4.1 most likely) and with that a high number of ref frames which do require a big amount of RAM for the decoder.

so please compare:

- type of video codec

if all share the h.264 codec, look further and compare

- h.264 level

- # of ref frames

- Bit Depth=10 ?

- anamorphic 1 or 0

- Scan type: progressive or interlaced?

Do also look out if any of the various video, audio and subtitle tracks are accompanied by the words 'zlib' or 'header stripping'.

Update: plex's xml does not tell this, use mediainfo instead.

Ah sorry I neglected to mention that, I understand how video containers work I just didn't mention it as I did a diff between the XMLs and didn't spot much other than the subtitle stuff. However, I've since opened them up with MediaInfo and this is what I get:

.mkv format version 4.2 on all
h264 on all (High@L4.1)
Ref frames 5 on all
Bit depth 8 on all
Aspect ratio 2.40:1 on all
All progressive scan
 
Also all the audio info is exactly the same.
 
Bear in mind that I selected no subtitles when I went to play, although I have also noticed that both of the ones that don't play have .idx files and .sub files, don't know if that makes a difference? Later on I might try deleting (well, moving) those files and trying to play again, see what happens. 
6

It shouldn't, since you selected no subs to play.

Do however check, if you activated automatic subs. Set 'subtitle mode' with 'manually selected'

Having said all that, give mkvclean a try on one of the slow movies anyway, as dane22 suggested. It reorders blocks and moves headers especially to the beginning of the file. Sometimes this is messed up and a 'not so smart' decoder will have to read the file as a whole before playback can start.

7

True, but I find that it solves about 90% of errors seen in the wild.

8

Thanks for the tip about the mkclean - unfortunately it didn't work...

HOWEVER

Deleting the .sub file did. Looking at the logs, I think it's actually trying to grab all the subs from the .sub file despite the fact that I set Subtitles to "None". In the plex logs I'm seeing what looks like a load of requests to grab various sections of the .sub file. I'm going to grab a clean log (one without media scans and whatnot) and submit it, as I don't think plex should be doing that. I don't know if it's a PMS issue or a PHT issue, though.

The lines I'm seeing are basically:

Sep 26, 2014 14:51:23 [0xa532bb70] DEBUG - Request: [192.168.0.13:48833] GET /library/streams/113905?encoding=utf-8&X-Plex-Token=xxxxxxxxxxxxxxxxxxxx (4 live)
Sep 26, 2014 14:51:23 [0xa532bb70] DEBUG -  * encoding => utf-8
Sep 26, 2014 14:51:23 [0xa532bb70] DEBUG -  * X-Plex-Token => xxxxxxxxxxxxxxxxxxxx
Sep 26, 2014 14:51:23 [0xa532bb70] DEBUG - We found auth token (xxxxxxxxxxxxxxxxxxxx), enabling token-based authentication.
Sep 26, 2014 14:51:23 [0xa532bb70] DEBUG - Came in with a super-token, authorization succeeded.
Sep 26, 2014 14:51:23 [0xa532bb70] DEBUG - Request range: 0 to 0
Sep 26, 2014 14:51:23 [0xb3e06b70] WARN - We didn't receive any data from 192.168.0.9:50034 in time, dropping connection.
Sep 26, 2014 14:51:23 [0xa66b3b70] DEBUG - Request: [192.168.0.13:48834] GET /library/streams/113905.sub?X-Plex-Token=xxxxxxxxxxxxxxxxxxxx (3 live)
Sep 26, 2014 14:51:23 [0xa66b3b70] DEBUG -  * X-Plex-Token => xxxxxxxxxxxxxxxxxxxx
Sep 26, 2014 14:51:23 [0xa66b3b70] DEBUG - We found auth token (xxxxxxxxxxxxxxxxxxxx), enabling token-based authentication.
Sep 26, 2014 14:51:23 [0xa66b3b70] DEBUG - Came in with a super-token, authorization succeeded.
Sep 26, 2014 14:51:23 [0xa66b3b70] DEBUG - Request range: 0 to 0
Sep 26, 2014 14:51:23 [0xa66b3b70] DEBUG - Content-Length of /mnt/user/Video/Movies/Movie/Movie.sub is 71489536.
Sep 26, 2014 14:51:55 [0xa66b3b70] DEBUG - Request: [192.168.0.13:48835] GET /library/streams/113906?encoding=utf-8&X-Plex-Token=xxxxxxxxxxxxxxxxxxxx (3 live)
Sep 26, 2014 14:51:55 [0xa66b3b70] DEBUG -  * encoding => utf-8
Sep 26, 2014 14:51:55 [0xa66b3b70] DEBUG -  * X-Plex-Token => xxxxxxxxxxxxxxxxxxxx
Sep 26, 2014 14:51:55 [0xa66b3b70] DEBUG - We found auth token (xxxxxxxxxxxxxxxxxxxx), enabling token-based authentication.
Sep 26, 2014 14:51:55 [0xa66b3b70] DEBUG - Came in with a super-token, authorization succeeded.
Sep 26, 2014 14:51:55 [0xa66b3b70] DEBUG - Request range: 0 to 0
Sep 26, 2014 14:51:55 [0xa532bb70] DEBUG - Request: [192.168.0.13:48836] GET /library/streams/113906.sub?X-Plex-Token=xxxxxxxxxxxxxxxxxxxx (3 live)
Sep 26, 2014 14:51:55 [0xa532bb70] DEBUG -  * X-Plex-Token => xxxxxxxxxxxxxxxxxxxx
Sep 26, 2014 14:51:55 [0xa532bb70] DEBUG - We found auth token (xxxxxxxxxxxxxxxxxxxx), enabling token-based authentication.
Sep 26, 2014 14:51:55 [0xa532bb70] DEBUG - Came in with a super-token, authorization succeeded.
Sep 26, 2014 14:51:55 [0xa532bb70] DEBUG - Request range: 0 to 0
Sep 26, 2014 14:51:55 [0xa532bb70] DEBUG - Content-Length of /mnt/user/Video/Movies/Movie/Movie.sub is 71489536.
Sep 26, 2014 14:52:00 [0xad575b70] DEBUG - NetworkServiceBrowser: PLAYER departed after not being seen for 181.882406 seconds: 192.168.0.8
Sep 26, 2014 14:52:23 [0xa532bb70] DEBUG - Request: [192.168.0.13:48837] GET /library/streams/113907?encoding=utf-8&X-Plex-Token=xxxxxxxxxxxxxxxxxxxx (3 live)
Sep 26, 2014 14:52:23 [0xa532bb70] DEBUG -  * encoding => utf-8
Sep 26, 2014 14:52:23 [0xa532bb70] DEBUG -  * X-Plex-Token => xxxxxxxxxxxxxxxxxxxx
Sep 26, 2014 14:52:23 [0xa532bb70] DEBUG - We found auth token (xxxxxxxxxxxxxxxxxxxx), enabling token-based authentication.
Sep 26, 2014 14:52:23 [0xa532bb70] DEBUG - Came in with a super-token, authorization succeeded.
Sep 26, 2014 14:52:23 [0xa532bb70] DEBUG - Request range: 0 to 0
Sep 26, 2014 14:52:23 [0xa66b3b70] DEBUG - Request: [192.168.0.13:48838] GET /library/streams/113907.sub?X-Plex-Token=xxxxxxxxxxxxxxxxxxxx (4 live)
Sep 26, 2014 14:52:23 [0xa66b3b70] DEBUG -  * X-Plex-Token => xxxxxxxxxxxxxxxxxxxx
Sep 26, 2014 14:52:23 [0xa66b3b70] DEBUG - We found auth token (xxxxxxxxxxxxxxxxxxxx), enabling token-based authentication.
Sep 26, 2014 14:52:23 [0xa66b3b70] DEBUG - Came in with a super-token, authorization succeeded.
Sep 26, 2014 14:52:23 [0xa66b3b70] DEBUG - Request range: 0 to 0
Sep 26, 2014 14:52:23 [0xa66b3b70] DEBUG - Content-Length of /mnt/user/Video/Movies/Movie/Movie.sub is 71489536.
 
There are a lot more lines of basically the same thing, that's just a snippet. Then it finally gets to:
 
Sep 26, 2014 14:54:34 [0xa66b3b70] DEBUG - Client [4160dc38-a4dc-45d9-bb32-219dda1dc6b1] reporting timeline state playing, progress of 0/8154198ms for guid=com.plexapp.agents.imdb://tt1843866?lang=en, ratingKey=34285 url=, key=/library/metadata/34285, containerKey=/playQueues/342, metadataId=34285
 
 
 
EDIT:
Update - logs added to first post
 
9

PHT allows the user to activate and switch between any subtitles present by using hotkeys during playback.
In order to have this ability PHT and PMS must scan and do a basic analysis of each subtitle file present.
So disabling the subtitles before starting playback only disables their display, not their initial analysis.

Normally this should not cause any problems, of course, but errors in subtitle files may cause problems for the parser code that scans them.

Best regards: dlanor

10

The latest PHT (1.3.2 which was released today) has some improvements in this area. There was a bug which downloaded and cached the vobsub locally once for every subtitle track that was in the sub. So if the sub had 10 languages in it, it was downloaded 10 times. This bug is now fixed and it only downloads and caches the sub once. This means that if you are sitter locally the movie should load quickly. If you are sitting remotely it will still take some time as vobsubs are often huge. But at least it only downloads it once :)

11

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.