Experimental TsReader development (4 Viewers)

[wouter1971]

Look at the TsWriter & TsReader logs yourself - you just have some continuity errors - probably bad signal reception.....

Tony

You say "probably bad signal reception" so I assume that means other things can cause continuity errors.

Anyway, I didn't have this strange problem with the sound getting stuck and then sounding like some sort of Max Headroom glitch before. It guess it could be the LAV decoder, as I haven't got round to installing SAF again yet so I'm using LAV rather than ffdshow for audio at the moment (still MS decoder for TV video).

The issue where the sound drops out for about a second has plagued me for ages though and I don't think it's due to bad signal as I don't get any picture corruption when it happens.

I guess I'll have to try recording what I'm watching and then I'll be able to see if I can reproduce the problems on playback or if they only happen live.

Doveman, i went through your logs and saw a lot of "PMT Pid wasn't found on the PAT. Channel may have moved, try a new channel scan." I guess you'd better do so and also enable the tv server debugoption "lookupPAT" as seen a few posts back. Just take the tv server shortcut on the desktop en enter the properties of it. Enter " /debugoptions" (without quotes) behind the "

It does not hurt to check if it helps

p.s. i also use the MS for video and use the default MPA decoder for s/pdiff out to get AC3 to receiver. Also disable DVBSub to test.

 

[doveman]

Doveman, i went through your logs and saw a lot of "PMT Pid wasn't found on the PAT. Channel may have moved, try a new channel scan." I guess you'd better do so and also enable the tv server debugoption "lookupPAT" as seen a few posts back. Just take the tv server shortcut on the desktop en enter the properties of it. Enter " /debugoptions" (without quotes) behind the "

It does not hurt to check if it helps

p.s. i also use the MS for video and use the default MPA decoder for s/pdiff out to get AC3 to receiver. Also disable DVBSub to test.

Thanks. I can't imagine I'd be able to watch the channel if it had moved, but I've rescanned and set the PAT option and disabled DVBSub to see if it helps. I only use analog audio output, mostly stereo.

 

[mrmojo666]

There's nothing I can see in the logs to explain what might be going wrong, but I'm not an expert on the TV server end of things.

RTSP runs different code at both ends of the system, so it's quite possible for something to work with singleseat and UNC but break with RTSP - sorry, but I can't help further.....

Tony

hi tony


i want to say the v41 is running perfect from days and as i told you before i can use rtsp also on wifi


about those 3 channel that i haven'y working on RTSP i've found the workaround i have to use the debugoption on server lookup PAT

now is all working very very smooth with tsreader v41, directshowv92nodwm and tvserver debugoption lookupPAT enabled

thank you for your brilliant work

sorry guys , but i was wrong ... today i can't watch again those 3 channels by rtsp......

from now i stop to be OT ehehe

 

[tourettes]

The issue where the sound drops out for about a second has plagued me for ages though and I don't think it's due to bad signal as I don't get any picture corruption when it happens.

It depends on luck if video or audio or both are affected by the randomly corrupted data. Also video decoder could just drop some frames that wouldn't be visible in (almost) static frames. So if you aren't seeing image corruption it still could be corrupted stream.

 

[wouter1971]

sorry guys , but i was wrong ... today i can't watch again those 3 channels by rtsp......

from now i stop to be OT ehehe

I guess those channels don't want you to watch, must be porn then
I have RTSP running smooth here with v41. I think the bit more aggesive settings are working nicely.
Haven't heart my girlfriend complaining about it, i do the tests in production so have to do it quick.

No logs?

 

[mrmojo666]

are you asking my logs ?

i've added before, but as usual i get back just complains about MDAPI, until i'll found free channel that are black by rtsp and ok by UNC i won't provide anymore logs.

luckly those channels are just clones (+1 hour and +2 hours) of other channels ..so i can do without them in case i can switch to unc mode

 

[Owlsroost]

You say "probably bad signal reception" so I assume that means other things can cause continuity errors.

Anyway, I didn't have this strange problem with the sound getting stuck and then sounding like some sort of Max Headroom glitch before. It guess it could be the LAV decoder, as I haven't got round to installing SAF again yet so I'm using LAV rather than ffdshow for audio at the moment (still MS decoder for TV video).

The issue where the sound drops out for about a second has plagued me for ages though and I don't think it's due to bad signal as I don't get any picture corruption when it happens.

I guess I'll have to try recording what I'm watching and then I'll be able to see if I can reproduce the problems on playback or if they only happen live.

If you have a server/client system using RTSP, dropped network packets will create continuity errors in TsReader log. As you have continuity errors logged at both ends it's highly likely to be signal problems (or possibly tuner driver issues etc - basically anything that might cause part of the broadcast stream to be dropped).

What the errors look like/sound like is dependant on how the decoders behave e.g. PDVD video decoders usually hide the errors by freezing the picture, but others display picture corruptions.

Tony

 

[doveman]

If you have a server/client system using RTSP, dropped network packets will create continuity errors in TsReader log. As you have continuity errors logged at both ends it's highly likely to be signal problems (or possibly tuner driver issues etc - basically anything that might cause part of the broadcast stream to be dropped).

What the errors look like/sound like is dependant on how the decoders behave e.g. PDVD video decoders usually hide the errors by freezing the picture, but others display picture corruptions.

Tony

Well I'm only using a single-seat setup, so don't think dropped network packets could be an issue.

I've tested after re-scanning and enabling the PAT debugoption and disabling DVB subtitles. I've found with some sound drop outs and picture freezes, they didn't happen if I rewound and replayed the same section, whilst other's did.

Hopefully the logs will show something. I recall one issue happened around 17:42 but I can't recall if it was one which only happened live or if it persisted when I replayed.

 

[doveman]

The issue where the sound drops out for about a second has plagued me for ages though and I don't think it's due to bad signal as I don't get any picture corruption when it happens.

It depends on luck if video or audio or both are affected by the randomly corrupted data. Also video decoder could just drop some frames that wouldn't be visible in (almost) static frames. So if you aren't seeing image corruption it still could be corrupted stream.

I don't know if you mean bad signal by "randomly corrupted data" but I'll assume so as I'm not aware that there's any other reason MP would be getting corrupted data.

I'd still think that if the signal was so bad that it couldn't decode the audio, the video would also be affected. In the cases where the audio drops-out for about a second, even if the scene is fairly static if there's someone talking I imagine I'd notice if the video skipped or froze.

 

[tourettes]

I don't know if you mean bad signal by "randomly corrupted data" but I'll assume so as I'm not aware that there's any other reason MP would be getting corrupted data.

Stream corruption / randomly corrupted data could be caused many different things - most of the time it is bad signal. For example:

• Long DPC latency caused by some driver (BDA driver has no change to deliver data and some of it needs to be discarded)
• Buggy BDA driver

I'd still think that if the signal was so bad that it couldn't decode the audio, the video would also be affected. In the cases where the audio drops-out for about a second, even if the scene is fairly static if there's someone talking I imagine I'd notice if the video skipped or froze.

Well, I have seen corrupted recordings on my own HTPC where some dropouts were affecting only the audio. Remember that it is completely random where the corruption usually hits. Transport Stream packets are 188 bytes long, and one packet carries only audio or video (or subtitle etc.). So with an extra bad luck you could have 1 hour long period of corrupted audio data and not a single hickup in video stream. Quite unlikely event, but losing 1 second of audio is much more likely (it depends much on the encoding and decoders how much a single lost audio packet will drop the audio stream in the decoding phase).