[1.3.0] No sound or video on client after wake when playing TV (1 Viewer)

[DragonQ]

I have MP TV Server running on my server 24/7. When I wake up my HTPC (running MP client) in the morning and try to play TV, I just get a blank screen with no sound. The only solution I've found is to restart the HTPC; restarting TV Server doesn't help.

I'm using the latest drivers for GPU and motherboard on my HTPC, and I'm restarting MediaPortal upon resume. I'm also using UNC paths because I've always had issues with RTSP stuttering. Sleep and resume seem to happen very smoothly, taking 2 and 3 seconds respectively. I can't see any firewall issues - I've run the batch file from the Wiki on both machines and the Firewall entries seem to allow everything necessary.

I've attached logs from both the client and server but they're pretty bare. I'll get debug logs next time.

 

[mm1352000]

Hi DragonQ

Indeed, debug logs would be appreciated.

From the TV Server logs I can see you're getting PMT timeouts on the first tune after the client wakes. Since your PMT delay is set to 10 seconds, the tuning process does two PMT waits per tune, you have 2 DVB-S/S2 tuners, and each tuner is tried twice... that's a sum of 10 x 2 x 2 x 2 = 1m20s when MP will appear to be frozen. If TV is full screen, screen would be black.

I also note the "FileReader::CloseFile() no open file" entries in the TsReader log. The issue there could be access to the UNC shares.

mm

 

[DragonQ]

The PMT timeouts are because the HTPC tried to tune to BBC Three (since that was the last channel viewed the night before) and BBC Three doesn't broadcast in the mornings. The fact that there's still no way to define part-time channels in MediaPortal to avoid this is annoying! However, this problem continued after it tried to tune to BBC Three so that isn't the only issue.

The "no open file" thing is interesting. If it's indeed a share access problem there may be some magical registry setting that'll fix it. I've enabled Debug logging so the next time it happens I'll upload those logs, and I'll also check if I can access the Timeshift share via Explorer.

 

[DragonQ]

It happened again when I turned on my HTPC after getting home from work. After it happened, I closed MediaPortal and checked that I could access both \\hda and \\192.168.1.99 - both worked fine. Debug logs attached!

Oh, and I restarted the HTPC and am now getting exactly the same issue. Blank screen, no sound. Oh dear! Had to restart the TV Service to fix it this time.

 

[mm1352000]

Although TsReader logs detection of video from the PMT, a video codec is not being connected.

2013-05-29 17:01:51.040799 [Debug][MPMain(1)]: TSReaderPlayer: Stream is Radio

29-05-2013 17:01:41.035 [5d8] pcr pid: 30
29-05-2013 17:01:41.035 [5d8] pmt pid: 20
29-05-2013 17:01:41.035 [5fc]demux:flushing
29-05-2013 17:01:41.035 [5d8] video pid: 30 type: MPEG2
29-05-2013 17:01:41.035 [5fc]demux:flush audio
29-05-2013 17:01:41.036 [5d8] audio pid: 40 language: eng type: MPEG2 - audio
29-05-2013 17:01:41.036 [5fc]demux:flush video
29-05-2013 17:01:41.036 [5d8] audio pid: 41 language: NAR type: MPEG2 - audio
29-05-2013 17:01:41.036 [5fc]demux:flush subtitle
nguage: eng type: DVB subtitle 2

Note: I see you're using a custom build of MP. Wonder if you could substitute the latest version of TsReader and try testing with that.

@Owlsroot ?

 

[DragonQ]

It's just the latest Custom Data Grabber version, nothing special. I've changed one thing on my network, and that is to give all users write access to the Timeshift and Recorded TV folders - I thought maybe my HTPC was having trouble deleting old timeshift files or something. I've also stopped using OpenDNS since it messes up hostname resolution within MediaPortal for some reason (bug?).

If I get the same issue again, I'll try updating the TsReader.ax file.

 

[mm1352000]

It's just the latest Custom Data Grabber version, nothing special.

Yeah, I know... but for us devs who don't use that version and don't really understand it... we'd still consider that "special".
Custom builds effectively have no support except from the person who created them.
I'm doing my best to help regardless, and just saying there is a possibility (slim though it may be) that the problem is related to that build.

 

[Owlsroost]

From the TsReader log, when it opens the timeshift file it's not getting any video (and probably audio, but I can't tell that directly from the log) within 10 seconds - it times out and gives up at that point. Note this has to be actual video stream data, not just the PAT/PMT info.

29-05-2013 17:01:41.054 [5d8]OnNewChannel: New Audio 4
29-05-2013 17:01:51.035 [5d8]demux:Start() end2 BytesProcessed:32336

Note the 10s gap between the two entries, and only 32KB processed in 10s elapsed time.

Interestingly, the server stops timeshifting just a short time later (at 17:01:51.773) :

29-05-2013 17:01:28.286 CDiskRecorder::Flush() - Throttle to 15416 bytes
29-05-2013 17:01:28.411 CDiskRecorder::Flush() - Throttle to 32336 bytes (max)
29-05-2013 17:01:51.773 Recorder: TIMESHIFT Stop 'C:\Timeshift\live8-1.ts.tsbuffer'
29-05-2013 17:02:03.555 Recorder: TIMESHIFT Reset
29-05-2013 17:02:03.555 CDiskRecorder::Reset() - Reset write buffer throttle
29-05-2013 17:02:03.555 del m_pVideoAnalyzer
29-05-2013 17:02:03.555 analyzer: reset

 

[DragonQ]

So what does that mean? I got the same problem this morning so it obviously wasn't a permissions error.

Same problem after restarting the HTPC and restarting TV Service. This is getting ridiculous now.

 

[mm1352000]

So what does that mean?

Something is causing the data not to be accessible.
My suspicions are either firewall or share issues due to network driver, permissions...

I got the same problem this morning so it obviously wasn't a permissions error.

That doesn't rule out an issue with shares or networking.

Same problem after restarting the HTPC and restarting TV Service. This is getting ridiculous now.

Just remember you're running a custom build with a certain plugin and the UNC option on OS versions which are not supported. Sometimes when we go outside the box there are issues like this.


I'd suggest pair back to the basics.
If you know the server works then that is a good start.
Get firewalls out of the way while testing.
If you can't or won't revert temporarily to a standard build then at least try the latest TsReader.
Also try the RTSP option. Even if it is stuttery it will help rule out share access/availability issues.