Very long delay before video starts to play

Dev Community Apps & Creations
1

Hey,

 

I'm using rasplex 0.4.0-rc3 on rPI 512MB, slightly overclocked:

arm_freq=850
core_freq=300
sdram_freq=400
over_voltage=4

I different playback behaviors for 2 similar MKV files. Both files have 1 video track, 1 DTS 5.1 track.

First file:

Stream #0:0(fre): Video: h264 (High), yuv420p, 1920x808, SAR 1:1 DAR 240:101, 23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc (default)
Stream #0:1(fre): Audio: dts (DTS), 48000 Hz, 5.1(side), fltp, 1536 kb/s (default)
Stream #0:2(eng): Subtitle: subrip (default) (forced)
 

Second file:

Stream #0:0(eng): Video: h264 (High), yuv420p, 1920x800, SAR 1:1 DAR 12:5, 23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc (default)
Stream #0:1(eng): Audio: dts (DTS), 48000 Hz, 5.1(side), fltp, 1536 kb/s (default)
Metadata:
  title           : English
Stream #0:2(eng): Subtitle: subrip (default) (forced)
Metadata:
  title           : English
 

When I start playback on the first one it starts after around 15 seconds (which is still slow, but manageable).

When I start the second one, I have to wait up to 5 minutes until it starts playing.

 

The buffer size doesn't seem to matter - I tried 3%, 6%, 10%. No changes.

 

I've attached the playback logs for both files - from hitting the "resume from" button, playing something for a couple of seconds, and stopping.

 

Can someone knowledgeable take a look? Any tips on making this faster? 15 seconds is already quite slow, 5 minutes is just unusable. 

2

I’m not sure how you extracted those logs, but they are both in an invalid format with HUGE dummy blocks preceding the normal log text.

“wrong.log” has a dummy block of 1157784 bytes.
“right.log” has a dummy block of 851836 bytes.

For both cases the dummy blocks consist of a LineFeed code followed by a long sequence of zeroes.
The existence of these dummy blocks makes it hard to read the log files in a normal editor.
I have removed those blocks from my copies of the files to simplify their evaluation, and am attaching those files here.

fixed_right.log (279 KB)
fixed_wrong.log (78 KB)

I’m not making any real analysis of those files myself now, but am merely providing the log files with the dummy blocks removed so as to simplify their analysis by others.

Best regards: dlanor

3

Ouch, thanks dlanor. I did an echo > plexhometheater.log right before I started playback to clean it up, then copied the log to the right / wrong files - but I didn't check their content before uploading, sorry about that. Something must have gone wrong somewhere in the process.

4

You are using Plex Media Server 9.9.5 and transcoding?  Have you tried with these files using DirectPlay instead?  

Is this via wired or wireless?  What are you running your Plex Media Server on (OS, CPU, wired/wireless)?

5

@zeflash : well 5 minutes seems really long to me but its hard to say what is happenning from the log you gave.

If you can get me a sample and link it somewhere then i can have a look :)

6

I know this is an old post but I'm having the exact same issue.  Some files are taking 5 mins or so to start to play.  They are fine when they start.

Did the original poster ever get this sorted?

7

I know this is an old post but I'm having the exact same issue.  Some files are taking 5 mins or so to start to play.  They are fine when they start.

Did the original poster ever get this sorted?

That's unknown but doubtful, since the last post in this thread before yours was a request for a sample file that we could test.
The same request obviously applies to your problem as well.

For a developer to really test an issue, he needs to replicate it in a lab scenario, and for cases like this one that requires a working sample to trigger the issue.

Best regards: dlanor

8

I'm occasionally having this same issue.  So far it has only been seriously delayed (5 min), when using files with DTS 6.1. 

9

I'm occasionally having this same issue.  So far it has only been seriously delayed (5 min), when using files with DTS 6.1. 

I understand how that would be very irritating, but I've never seen this kind of delay myself.

And as stated in other replies: In order to test a problem we need to be able to replicate it somehow.

So if you could provide a sample exhibiting this problem, then we'd have something to work with.

Best regards: dlanor

10

DTS 6.1 is a special case, it has to be decoded by the Plex Media Server since RasPlex doesn't know how to bitstream it to a receiver or, if I remember correctly, decoded it itself.  And to make things more complicated, it doesn't seem to be consistent when it comes to DTS 6.1 streams...

In the scenario you are describing though, I strongly suspect that PMS is decoding the audio and remuxing the stream so that RasPlex can play it.

DTS 5.1 in pass through mode shouldn't show this issue though, assuming PMS doesn't misunderstand the audio format and attempts to decode and remux it...

11

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