[confirm] LiveTV blank screen no sound on client video and sound works on server (1 Viewer)

[Owlsroost]

Hi folks

I had a look at the logs again with the TsReader and MP code last night, and to me it looks like TsReader is simply not notifying MP that there is video in the stream. However, I'm comparing to my own logs for a standalone install. Instructions for using RTSP on standalone or logs (server + client) for a remote client and live TV would be extremely helpful.

mm

A thought - for someone who has the problem, what happens if you do a live TV channel change (without stopping TV) ? (logs for this situation might be interesting too)

(in theory, channel changes should trigger 'OnVideoFormatChanged' processing in TsReaderPlayer, which should then update the video/audio stream info etc)

EDIT: just realised that this won't happen in the 'capturing from an STB output' because the stream info will never change (I presume)...

Tony

 

[Owlsroost]

Actually, looking at the client logs, there's no 'OnNewChannel' anywhere (no PAT detected?), so is the server not sending enough data for some reason ?

(the logs suggest it's asking for about 1 sec of the stream to be played when RTSP is first started, presumably to allow for initial PAT/PID parsing, but it's not happened 5 sec later when it's closed and re-started for normal playing)

Tony

 

[thirdoff]

When I change channel within tvserver, after starting a stream in manual streaming section the stream will crash and rename itself to stream2.1, etc but still only connects to a blank screen.

I must be clear, I can ALWAYS connect to a running stream in VLC. I can only change channel from the STB manually (with USB-UIRT) it's only the client that shows blank.

 

[mm1352000]

Hi again thirdoff

Have you upgraded to the latest Colossus driver? At this point I'd recommend doing that. Apparently some PMT related issues are resolved in the latest versions. You'll need to apply a small patch on top of the All_Colossus_HDPVR_Patch(v2).zip patch that you already applied. You can find it attached to the first post of the Colossus thread. After that, please provide us with a new set of logs.

mm

[Edit: Tony, you mentioned that PAT is missing. I'm not sure that the Colossus actually injects PAT into the stream. It uses a fixed SID (=1). Does that make a difference to this discussion? Perhaps we need a short (~20 second recording of a Colossus stream)...]

 

[Owlsroost]

[Edit: Tony, you mentioned that PAT is missing. I'm not sure that the Colossus actually injects PAT into the stream. It uses a fixed SID (=1). Does that make a difference to this discussion? Perhaps we need a short (~20 second recording of a Colossus stream)...]

Hi mm,

If the Colossus works OK in single-seat mode (which I assume it does) then the stream it produces *should* be OK for RTSP as well (the same parsing code is used in TsReader, as far as I can tell). So I suspect the demux is just not getting any data - or any data that it can make sense of - in the 5 sec before the RTSP logic times out and closes the connection.

I think we need some more TsReader debug logging to get much further with this....

(It isn't just some sort of firewalling issue at the client is it ?)

Tony

 

[Owlsroost]

I've now got a working server/client setup, so if someone can upload a short Colossus recording I can try playing it over RTSP.....

(RTSP log attached for reference)

Tony

 

[mm1352000]

Hmmm, I see what you mean - it is very obvious when you compare logs side by side. The PMT can take a while to arrive with the Colossus/HDPVR. Would it be worth me throwing together a build that bumps up the timeout?

mm

 

[Owlsroost]

Hmmm, I see what you mean - it is very obvious when you compare logs side by side. The PMT can take a while to arrive with the Colossus/HDPVR. Would it be worth me throwing together a build that bumps up the timeout?

mm

Probably (if you can workout where the 5s timeout is in the code - I couldn't....)

This info in this thread - https://forum.team-mediaportal.com/submit-code-patches-mediaportal-tv-server-etc-325/slow-rtsp-startup-causes-eof-indication-96460/ - suggests that if *no* data was arriving at the client in time we would see EOF messages in the log, so it does look more like TsReader can't make sense of the data.

thirdoff - does playback of recordings work OK, or is it just live TV that's broken ?

Tony

 

[Owlsroost]

thirdoff - attached is TsReader.ax with extra logging in the demux Start() function - please try and post the logs, it should produce lines like

demux:Start() BytesRead:39480, BytesProcessed:78960

in TsReader log.

Basically, this should prove if any stream data is being received by the client.

Thanks,

Tony

 

[thirdoff]

Ask and ye... well you know. Attached is log requested.
I see a lot of 0 bytes processed.
I'm sure you already got this part but just to repeat myself. I can watch the stream just fine on VLC on the client PC while stream source from TVServer is on another PC.
I replaced the file above on the client, correct?