TS record bug/issue (1 Viewer)

[onelegend]

Hi all

This issue has happened in the past but very rare, It has happened a few times in the last 2 weeks though (my folks have a duplicate system in their house which it has also happened). It happened tonight whilst recording BBC Hd The Voice

Basically the signal lock is bad, thus a unwatchable/corrupted recording - fragments of video and constant audio breakup. It has happened whilst watching live tv and a channel change/stream stop/start (even to the same channel) fixes... a recording this isnt possible.

Not much of an expert on the logs so have posted (I am using mdapi - its so rare that I will struggle to repeat on a clean install, also on beta as need to build my own custom data branch for final)

I did notice in the tswriter log - it picked up the error on lock.... and continued to report this error over and over until the recording stop - I know the issue is probably a gremlin and could be down to the tuner/driver etc

BUT

Since it detected a bad/poor signal - is it possible to have a feature where it can drop the signal and attempt a relock after say 4 errors detected? This should allow a recording to recover and be watchable.

(Serious waf point drop when a recording fails )

Attached logs, hope they are of use

Thanks
Ian

 

[HomeY]

/// (I am using mdapi - its so rare that I will struggle to repeat on a clean install, also on beta as need to build my own custom data branch for final)

Sorry Ian, but mdapi isn't supported by the team.
https://forum.team-mediaportal.com/threads/mdapi-softcam-support-again.12620/

 

[onelegend]

I know

But media portal shouldn't sit on an error - which is what my post was more about

Im pretty sure this error would occur even without mdapi

It was more of a feature request of attempting to retune once a bad signal/error detected, as per logs - the error is detected but nothing is done about it, apart from an unwatchable recording.

Also Media portal goes unresponsive/unusable attempting to play the recording - again, this shouldn't happen (think a bug report for this already exists)

This seems to happen on bbc hd only on my system

 

[mm1352000]

You seem to have assumed that continuity errors are caused by signal issues... but in fact they can be caused by anything that causes packets to be lost/dropped or arrive at TsWriter out of order.

But media portal shouldn't sit on an error - which is what my post was more about

I wouldn't say MP is sitting on an error. In situations like that we're fighting tooth and nail not to have the TvService crash!
The smallest corruption could cause a crash for loosely written code.
Sure, we're not retuning... but as above... "continuity error" does not equal "signal issue". It is even highly debatable that retuning would help even with a signal issue. I would argue that in 90% of cases retuning wouldn't make diddly squat difference.

The only cases it might make a difference in that I can think of are:

• ...if there is an issue with the driver algorithm for locking on signal - ie. tuner not locking on exactly the optimal frequency, but getting close enough to be okay most of the time - and a retune gets the tuner closer to the optimal frequency. Retuning in that very specific case would be a heavy-handed solution to a very tuner/driver-specific issue which is far better addressed by the driver engineers.
• ...if your satellite dish LNB is on its way out and the local oscillator frequency has started to drift with changes in temperature. There has been a bit of this going on in NZ with a very specific brand/model of LNB and the problems are immediately solved by replacing the LNB.

See here for a possible example of what I'm talking about with the first point:
http://www.tbsdtv.com/forum/viewtopic.php?f=27&t=211&sid=0da855d4666a51db5f9c2c6d25589ffa

Im pretty sure this error would occur even without mdapi

Well, we require more than being "pretty sure". Sorry, I know it may be hard, but that is the requirement.

It was more of a feature request of attempting to retune once a bad signal/error detected, as per logs - the error is detected but nothing is done about it, apart from an unwatchable recording.

As per above - I honestly don't think it will help.

Also Media portal goes unresponsive/unusable attempting to play the recording - again, this shouldn't happen (think a bug report for this already exists)

MP trusts you.
If you tell MP to play a corrupt file then TsReader will do its darndest to play it.
The problem is that attempting to play a corrupt file can cause crashes and freezing as a natural side effect of playing garbage.
So the options are basically attempt to play or give up.
MP has gone with the first approach.

This seems to happen on bbc hd only on my system

...so try adjusting the frequency for the channel up or down by a few MHz and see what happens.

Well, there is my take on it anyway, for what its worth...

mm

 

[Owlsroost]

Also Media portal goes unresponsive/unusable attempting to play the recording - again, this shouldn't happen (think a bug report for this already exists)

MP trusts you. If you tell MP to play a corrupt file then TsReader will do its darndest to play it. The problem is that attempting to play a corrupt file can cause crashes and freezing as a natural side effect of playing garbage. So the options are basically attempt to play or give up. MP has gone with the first approach.

+1...

Decoding complex video streams (like H.264) gets near impossible if the data is badly corrupted, so effectively the filtergraph hangs/becomes unresponsive and MP can't control it - so often the only thing you can do is force it to quit using Task Manager. It's generally not the MP parts of the filtergraph having problems, it's the third-party video decode filters which can't cope (and to be realistic, you can't expect them to handle really badly corrupted streams). If the data is corrupted, it's corrupted - end of story, really.

Tony

 

[onelegend]

Thanks for your reply Mm

As I said in my other thread - I'll run with stock 1.3 to eliminate mdapi (this has only been a problem in the last week, thus my reasoning of not believing it to be the cause, this hasn't changed/updated). I shall try installing 1.3 final over the top of my current Custom Data Grabber build (Custom Data Grabber pulls in the channel frequencies from Sky - so tuning details should not be the issue, or could it just be the 6981 is crap at its job).... the only other cards that look reasonable are the Digital Devices, their the same price as a Sky HD receiver though.

I shall write an email to TBS as well to fire the question off. I find it strange that it's started happening the last week in 2 different houses.
Weather? - My Sky box has not experienced any problems with tuning - the receiver is next to the HTPC so cable run length is the same (I shall swap the LNB cables from the receiver to the HTPC). This as you said it could be the TBS driver/Sky receiver being more reliable to a duff signal lock.

I'll clone the recording schedules meanwhile until this is resolved - 3 systems, 1 of them should get the recording.

 

[radical]

Hi,

I also got issues with live TV and recordings on an TBS 6981 by using mdapi.
I am aware that it's not supported, but I'm curious if my problem is also caused by the use of MDAPI.
It does not happen all the time, but quite often.

Description:
If a ts-stream is switching from multiple audio tracks (e.g. DD 5.1 German/DD 5.1 English) to single audio track (e.g. DD 2.0) I get an corruption at the moment of change.

On live tv the transmission freezes. I must stop and restart live tv. (I think TS-Reader can't handle the change)
Recordings are corrupted from the moment of switching. On editing with TS-Doctor i get an error message that some stream is not listed in pmt-table.

 

[mm1352000]

Recordings are corrupted from the moment of switching.

More likely recordings are encrypted from the moment of switching.

 

[radical]

In my opinion they are not encrypted.
Video and audio are still there. No blank frames or any other interruptions.
It's more like the old stream is overwritten by the new stream.

Of course, I could be wrong with my guess.

 

[mm1352000]

Start a new thread, post full logs.
If you can, please reproduce without M****.
Post the link here so that I get a notification.