T2 picture breakup (as passthrough tuner and in recording)

[Paul_oz53]

Hi Bodogbodog,

We are using a " Bluey". See: https://m.ebay.com.au/itm/USB-2-0-Digit ... 8015894408

This has much better performance than the standard USB tuner. Much closer to the standard tuners in performance.

[Grumpy_Geoff]

We still have problems with pixelated recordings from time to time using the USB tuner - is there a reliable fix for this issue that I can implement to fix this? (I'm not deeply technical so need the solution describe in laymans terms) - Thanks

Which USB tuner - the Beyonwiz-supplied MINI (ITE 9135 chipset) USB tuner dongle or the far superior chipsets of the Realtek RTL2832U / Rafael Micro R820T tuner?

Nothing much has changed since your post of last year, except far more people have dumped the ITE tuner for the Realtek / Rafael Micro combination.

[Bodogbodog]

Thanks Paul_oz53 and Grumpy Geoff - much appreciated

I'll give the Bluey a go - if I can fix the issues for $16 for a new USB tuner my WAF will be positively glowing


I'll read back through the posts but do I basically just plug it in to replace the one that came with the T2?

[Grumpy_Geoff]

I'll read back through the posts but do I basically just plug it in to replace the one that came with the T2?

You can start from your post on page 5.

You can get either a 'Blackie' or a 'Bluey' as effectively they are the same thing.

If you're running 20180417 or later then, yes - plug and play.
Otherwise download the "dvb-usb-rtl2832" driver and install via PLUGINS.
Get a short USB extension cable to use too, as the blackie or bluey is bigger than the MINI and blocks both the HDMI and ethernet ports. Or you can use a USB hub.

Blackie - https://ae01.alicdn.com/kf/HTB1wuYUHVXX ... -Input.jpg
Bluey - https://ae01.alicdn.com/kf/HTB15IWYLVXX ... R820T2.jpg

[Paul_oz53]

...
I'll read back through the posts but do I basically just plug it in to replace the one that came with the T2?

Yes. It's fatter than the original so it's best used with a short extension or USB hub.

Some people report an occasional problem of their USB tuner not being recognized as the correct type but I haven't seen that problem. If it's working ok it will show as DVB-T in the hardware llisting.

[sub3R]

... but do I basically just plug it in to replace the one that came with the T2?

Yes as Geoff & Paul mentioned. But after plugging it in make sure you do a boot (or reboot). Then check in ‘MENU > Setup > Tuners > Tuner configuration’ to confirm that it has been enabled as a terrestrial tuner (DVB-T or DVB-T2). A GUI restart should enable it as DVB-T anyway if it has been enabled as a cable or satellite tuner (-C or -S).

Edited to correct GUI restart to boot/reboot.

[vader1111]

We still have problems with pixelated recordings from time to time using the USB tuner - is there a reliable fix for this issue that I can implement to fix this? (I'm not deeply technical so need the solution describe in laymans terms) - Thanks

The solution is to replace the USB tuner which comes with the unit. Get yourself a "bluey" or "blackie" (Realtek RTL2832U demodulator / Rafael Micro R820T2 tuner). These units don't have the same picture breakup problems that the Beyonwiz supplied units have in many areas.

You can buy these for around $14 on eBay (including free postage).

[Grumpy_Geoff]

... but do I basically just plug it in to replace the one that came with the T2?

Yes as Geoff & Paul mentioned. But after plugging it in make sure you do a GUI restart...

I'm pretty sure a (re)boot is needed, so that the kernel can load the drivers.

[sub3R]

Ah yes, a different device with different drivers. I’ll edit my post to avoid confusion.

[raymondjpg]

You can get either a 'Blackie' or a 'Bluey' as effectively they are the same thing.

If you can find a 'Blackie'. I had three goes originally to source one; despite having R820T in the product description the first two did NOT have the Rafael Micro R820T tuner. Recently I have tried to source another on eBay but had zero success at getting any response from the sellers regarding confirmation that they contained the right tuner.

I have instead ordered a 'Bluey' which claimed in its product description that its tuner was "based on the Rafael Micro R820T tuner". It remains to be seen whether or not it does contain the Rafael Micro R820T tuner, but I haven't seen any reports that 'Blueys' contain anything else.

Fingers crossed.

[sub3R]

Fingers crossed.

I you ordered from bestoou on eBay I think you will be okay.

[Bodogbodog]

I you ordered from bestoou on eBay I think you will be okay.

That's the place I've ordered from
I'm a "bluey"

Thanks to everyone for your help and advice on resolving this

[raymondjpg]

Fingers crossed.

I you ordered from bestoou on eBay I think you will be okay.

If my Hong Kong experiment doesn't work I'll try that. Thanks.

[Bodogbodog]

Just an update and a big Thank You to everyone for the advice

I received the Bluey this week from Bestoou and have upgraded the firmware to 17.5 - put the Bluey in the rear USB after the upgrade and all working

so far so good in terms of signal quality, no tearing of the picture when using all three tuners for recording

Only issue I had was restoring a couple of Mount Points that had previously worked fine - I think I've got it sorted now and hopefully they "stick" - they disappeared overnight which was a bit disconcerting. But I reset them and they're there for the moment

Who would have though a $15 eBay tuner could fix the breakup issue (fingers still crossed) - thanks to the Community for all the hard work tracking this down

[Peter D]

Bestoou is no longer registered on Ebay.

Can anyone recommend another seller?

Peter

[adoxa]

I may have a software solution for this, if anyone would like to try. It's worked on ABC HD; last night I tried ABC ME (36 minute test, nothing in log, nothing apparent upon viewing), One (one hour test, logged two retunes, breakup fixed on viewing) and Seven (one hour test, nothing in log, nothing apparent).

It seems the driver sets the transport error indicator; when the recording (this solution won't work in live TV, not sure about timeshift) detects three errors in a row it will force a retune. That's enough to reset the driver, restoring the picture.

[Grumpy_Geoff]

Bestoou is no longer registered on Ebay.

Can anyone recommend another seller?

You don't need to specifically purchase an R820T2/bluey as an R820T/blackie is just as good.
I wouldn't buy from any eBay listing that doesn't specify the tuner as being either an R820T or R820T2 in the item specifics though.
This one does "Chipset: RTL2832U R820T2" (a blackie with a R820T2?) - https://www.ebay.com.au/itm/292623852501
This one mentioning and showing a Raphael Micro tuner chip - https://www.ebay.com.au/itm/113167506143
Compared to this one that _doesn't_ (only mentioned in the title) - https://www.ebay.com.au/itm/252605314818

Possibly any bluey will be okay, as the case printing specifies an 820T2.
This one does specify an R820T2 "R820T2+RTL2832U chip" - https://www.ebay.com.au/itm/381673558300
As does this "R820T2+RTL2832U chip" - https://www.ebay.com.au/itm/183304138471

I don't know anything about these sellers though.

[Grumpy_Geoff]

I may have a software solution for this, if anyone would like to try. It's worked on ABC HD; last night I tried ABC ME (36 minute test, nothing in log, nothing apparent upon viewing), One (one hour test, logged two retunes, breakup fixed on viewing) and Seven (one hour test, nothing in log, nothing apparent).

It seems the driver sets the transport error indicator; when the recording (this solution won't work in live TV, not sure about timeshift) detects three errors in a row it will force a retune. That's enough to reset the driver, restoring the picture.

Is your change looking for a succession of [eMPEGStreamParserTS] errors ('dropping huge adaption field' or 'broken startcode')?
The U4 driver for the ITE 9135 already does that or similar, but just not soon enough (I've seen it delayed for 44 mins).
The T2 driver never does it; hence your changes.

Those log entries seem to not appear until around three minutes after the image issue first appears, as per my observations from my previous testing.

Live TV would be less of an issue, as one can zap broadcasters and back again to force a retune. If timeshifting doesn't force the retune, then obviously that'll continue to be a problem.

I can give your change a go on our T2 as I can swap back to the ITE dongle. The T2 is on 20180417 though, if that matters.

I could give it a try on the U4, though we'd need a way of seeing/proving if it is your change or the original driver doing the retune (I've seen the driver do it as quick as 2m:40s after the errors appeared in the log).

[adoxa]

Is your change looking for a succession of [eMPEGStreamParserTS] errors ('dropping huge adaption field' or 'broken startcode')?

No, I started with "broken startcode", but then discovered the transport error, which happens much sooner. Indeed, with the ABC HD test, I was skipping every 15 seconds and only caught a couple of breakups; the log showed a few more. Same with One, I skipped right over them, had to look at the log to see when they occurred - just a couple of glitches, a slight pause when it retuned, then all good.

I can give your change a go on our T2 as I can swap back to the ITE dongle. The T2 is on 20180417 though, if that matters.

The binary hasn't changed much, so that shouldn't be an issue.

I could give it a try on the U4, though we'd need a way of seeing/proving if it is your change or the original driver doing the retune (I've seen the driver do it as quick as 2m:40s after the errors appeared in the log).

As hinted above, my retune occurs seconds after the errors and I log when the retune happens. Couldn't really say if it will work with the U4, but if you're willing to try I'll compile it and we can find out...

[Grumpy_Geoff]

Is your change looking for a succession of [eMPEGStreamParserTS] errors ('dropping huge adaption field' or 'broken startcode')?

No, I started with "broken startcode", but then discovered the transport error, which happens much sooner. ...

Oh right, that's what you did say. Timewise, that then is much better than waiting for the logged errors.

...Couldn't really say if it will work with the U4, but if you're willing to try I'll compile it and we can find out...

I can test on either the T2 or U4 or even both. Load me up

[adoxa]

Here's tuner recovery patches for the T2 and U4. When the errors are detected the log will contain [eDVBServiceRecord] record tuner error (for recordings) or [eDVBServicePlay] record tuner error (for timeshift).

[Grumpy_Geoff]

Here's tuner recovery patches for the T2 and U4. ...

Installed it on the U4. Got a 'Text file busy' error when the install was attempting to copy the binary, so I copied it manually. I should have stopped the UI first
Testing has started.

T2 is busy until later this evening.

["Birthday boy" will probably be too busy to give this a run today on his U4 ]

[adoxa]

Installed it on the U4. Got a 'Text file busy' error when the install was attempting to copy the binary [...]

Sorry, it was an old installer and I forgot about that. I expect the same thing will happen on the T2. Just run it again to restore the backup, then the next install should work okay.

[Paul_oz53]

Here's tuner recovery patches for the T2 and U4. ...

Installed it on the U4. Got a 'Text file busy' error when the install was attempting to copy the binary, so I copied it manually. I should have stopped the UI first
Testing has started.

T2 is busy until later this evening.

Also loaded it manually before seeing the "try twice" update.

But it may be wasted on me anyway. A scan of my U4 logs has no [eMPEGStreamParserTS] entries. Generally I don't have a picture breakup problem with the U4 or the T3. Mainly get that on the T4. Ditto the fail to set the USB tuner to the correct type.

["Birthday boy" will probably be too busy to give this a run today on his U4 ]

Huh?

[IanSav]

Hi Paul,

["Birthday boy" will probably be too busy to give this a run today on his U4 ]

Huh?

Happy 65th Birthday!

Regards,
Ian.

[Grumpy_Geoff]

...But it may be wasted on me anyway. A scan of my U4 logs has no [eMPEGStreamParserTS] entries. Generally I don't have a picture breakup problem with the U4 or the T3. Mainly get that on the T4.

You won't get them if you're running the Realtek/Rafael Micro chipsets dongle. You have swapped to the ITE chipset (Beyonwiz MINI) dongle for this testing haven't you?

Ditto the fail to set the USB tuner to the correct type.

You won't get that tuner "mode-itis" issue if you keep your T3 in standby. The U4 doesn't have that issue.

["Birthday boy" will probably be too busy to give this a run today on his U4 ]

Huh?

Well I though you'd be out being wined and dined by your loved ones, and by the time you got home you'd be full of beer, wine and spirits.

[Grumpy_Geoff]

Here's tuner recovery patches for the T2 and U4. When the errors are detected the log will contain [eDVBServiceRecord] record tuner error.

It appears to be working, at just over 4.5 hours into the testing.
Retuning has occured eight times on the ABC network so far.

From the log I calculated the interval to the first retune (15m:50s) - blink and you'd miss it
Wife has just got home and taken control of the U4, so I had to resort to watching via SMB for the next lot!
Second retune was 29m:20s after the last retune (45m:12s into recording). Another small glitch.
Third retune was 37m:47s after last (82m:59s into recording). Glitch was a bit longer, but content was still very much viewable.
Fourth retune was 7m:12s after the last (90m:11s into recording). Scene transition right at the spot of the retune made it hard to tell it had actually occurred!
Fifth retune was 20m:14s after the last (110m:25s into recording). Again, minor.
Sixth retune was 35m:44s after the fifth (146m:9s into recording). Yep, minor.
Seventh retune was 57m:29s after the sixth (203m:38s into recording). You guessed it - minor glitch.
The eighth retune was 12m:32s after the last (216m:10s into recording). A glitch of about a second.

About ten hours more testing to go

[Paul_oz53]

Thanks for the best wishes guys. It was a good evening with the other half. Out with the family tomorrow.

Hadn't dawned on me that I need to downgrade the USB tuner to trigger the problem. Hardest part may be finding the damn thing!

Probably won't be doing anything before Friday. Busy until then.

[Grumpy_Geoff]

It appears to be working, at just over 4.5 hours into the testing.
Retuning has occured eight times on the ABC network so far.
...
About ten hours more testing to go

Recorded for 15 hours on the ABC network.
There were 22 retunes ([eDVBServiceRecord] record tuner error).
No time right now to further check recordings, although I don't expect any difference from what I reported earlier.

Confirming that on live TV with no current recordings on the broadcaster, there is no auto-retuning on [eMPEGStreamParserTS] broken startcode errors.
There's also no auto-retuning if behind live and viewing from the timeshift buffer.

[adoxa]

I don't think this method's possible with live (the software doesn't receive the packets) but I'll see if I can get it working with timeshift.

[adoxa]

Updated the previous post (they're there twice, both the same, didn't want to risk editing it again, dumb forum) with timeshift support (which also means live TV when you're saving it).

[adoxa]

Here's the source. I could possibly add a retune function to eDVBServiceBase, as well as eDVBChannel.

[Grumpy_Geoff]

Well, this is pleasantly unexpected...

The U4 has been running the mark-2 version of the tuner patch since yesterday afternoon. I left it showing live TV from the standard Beyonwiz MINI (IEC chipset) USB tuner since that time.
I wasn't recording from the USB tuner.
Checking this morning, the live TV image is still fine
Checking the log, there have been no '[eDVBServiceRecord] record tuner error' entries, which isn't suprising since I'm not recording from the USB tuner.
However, there have been 36, of the new for this patch, '[eDVBServicePlay] record tuner error' entries.

Going by the same event repeating in the available timeshift buffers listing, I thought the retunes may have resulted in the start of a new buffer segment. However looking at the debug log for around the time of 'Everyday Gourmet' I couldn't see a retune occuring.
I saved the two 'Everyday Gourmet' segments and had a quick look at them; I couldn't see any transmission errors between the two.

59933 => 08:29:46 today
59934 => [eDVBServicePlay] Start timeshift!
60269 => 5m:35s later -> [eDVBServicePlay] Start timeshift!

60803 => 8m:54s later -> [eDVBServicePlay] record tuner error

Code: Select all

{724}< 59933.309> [eDVBServicePlay] pts of eit change: 84f0a87b, fixup_pts: 7db83a8, first_pts: 7d1524d3
{724}< 59933.310> [eDVBServicePlay] no cue sheet
{724}< 59934.295> [eDVBServicePlay] [Timeshift] stopTimeshift
{724}< 59934.587> [eDVBServicePlay] remove timeshift files
{724}< 59934.628> [eDVBServicePlay] Start timeshift!
{724}< 59934.629> [eDVBServicePlay] timeshift recording to /media/hdd/timeshift/timeshift.C8V4kM
{724}< 59934.635> [eDVBServicePlay] unpause
{724}< 59937.012> [eDVBServicePlay] pts of eit change: 84f59a1b, fixup_pts: 34bc0, first_pts: 84f24e5b
{724}< 59937.013> [eDVBServicePlay] no cue sheet
{724}< 60268.826> [eDVBServicePlay] pts of eit change: 86bd73c3, fixup_pts: 1cb2568, first_pts: 84f24e5b
{724}< 60268.827> [eDVBServicePlay] no cue sheet
{724}< 60269.811> [eDVBServicePlay] [Timeshift] stopTimeshift
{724}< 60269.927> [eDVBServicePlay] remove timeshift files
{724}< 60269.931> [eDVBServicePlay] Start timeshift!
{724}< 60269.931> [eDVBServicePlay] timeshift recording to /media/hdd/timeshift/timeshift.iFFnoD
{724}< 60269.937> [eDVBServicePlay] unpause
{724}< 60803.256> [eDVBServicePlay] record tuner error

'pts of eit change' - is this just Network TEN buggering up its EITs or now/nexts causing the buffer changes?

[prl]

'pts of eit change' - is this just Network TEN buggering up its EITs or now/nexts causing the buffer changes?

PTS is the Presentation Time Stamp, the time at which some item in the media stream is supposed to be presented to the user (relative to other PTS timestamps). It's used to align, for example, video, audio and subtitles so that after they are demuxed from the packet stream the various parts can be presented at the correct time.

The message "pts of eit change" simply refers to the time (in PTS units) that the EIT now/next data changed. The PTS that will be recorded in the cuesheet (and .cuts file) is relative to the PTS of the start of the recording. The fixup is simply (in most cases) subtracting the recording's start PTS from the PTS of the now/next change.

However, life's never that simple. PTS values are 33 bits, and represent time in units of 1/90000 sec. That means that they will wrap around in just over a day (every 95443 sec, or about every 26.5 hours). That means that sometimes the PTS of the now/next timestamp is less than the PTS for the start of the recording, and that must be taken into account in the calculation.

Anyway, you should get a "pts of eit change" message each time there is a change in the now/next data. I think you should also get one when signal has been lost and regained (it's been a while since I looked at this code).

However, none of that precludes the broadcaster messing up the PTS timestamps or the EIT. You just can't assume that that must be the case.

[Grumpy_Geoff]

I think it could have been Network TEN dicking around. I've had the U4 on live TV on the Seven Network via the USB tuner for the last three hours, there have been twelve retunes ([eDVBServicePlay] record tuner error) but no "false" timeshift buffers were created. There are five buffers, which match the five events broadcast.

[prl]

Changes I made a while ago should stop new timeshift buffers being created when the tuner loses sync and then regains it.

[Grumpy_Geoff]

Changes I made a while ago should stop new timeshift buffers being created when the tuner loses sync and then regains it.

Yep that would appear to be the case, as there's been 19 retunes since the initial service tuning 5 hours ago, and there's still only the 5 buffers (the current event is an AFL match, since 14:30).

[Grumpy_Geoff]

I had the U4 on live TV playing the Seven Network via the Beyonwiz MINI (IEC 9135) USB tuner for over 8 hours yesterday without image issues, and with no unexpected additional timeshift buffer creation.

I then watched some recordings, and went back to live TV playing the Seven Network around 21:45. It has been on live TV since then, and again with no unexpected additional timeshift buffer creation (the buffers match www.ourguide.com.au). The image is still fine after overs 12 hours of continously being on 7flix. There have been 20 retunes.

I think this change is a success - despite adoxa thinking his change wouldn't fix the live TV issue.

Well done adoxa

[MrQuade]

I think this change is a success - despite adoxa thinking his change wouldn't fix the live TV issue.

His second release added the timeshift mod which would have fixed Live TV.
Did you try watching Live TV without timeshift enabled? I would have thought that the glitching would resume then.

[adoxa]

I think this change is a success - despite adoxa thinking his change wouldn't fix the live TV issue.

As MrQuade points out, live is only fixed if timeshift is being saved; with timeshift disabled live errors will not be detected.

Well done adoxa

Cheers. It's nice not having to wonder if the third tuner will work. Now to submit it...

[Grumpy_Geoff]

I think this change is a success - despite adoxa thinking his change wouldn't fix the live TV issue.

His second release added the timeshift mod which would have fixed Live TV.
Did you try watching Live TV without timeshift enabled? I would have thought that the glitching would resume then.

I read the comment " with timeshift support (which also means live TV when you're saving it)." as meaning if you're saving the current event. But since I wasn't saving any buffer event, although I did step back into the buffers at one point to check the retune, that's not the case.
I haven't tested with timeshift disabled. I just started a test of that now (disabled, changed broadcasters to have new setting used, zapped back to 7HD). The glitching should appear within a few hours!
How many people would run without timeshift being enabled?

[Grumpy_Geoff]

Well done adoxa

Cheers. It's nice not having to wonder if the third tuner will work. Now to submit it...

The USB tuner can still have an issue - tuner "mode-itis" can hit it; if you want a new mission then that could be it

[MrQuade]

I read the comment " with timeshift support (which also means live TV when you're saving it)." as meaning if you're saving the current event.

I read it such that the stream must be getting written to disk in any manner for the errors to be detected.


Anyone who is running without a hard-disk may be running without timeshift enabled, though you are correct, the number of people doing so would be low.

[IanSav]

Hi,

While this patch appears to address the problem it is a bit of a hack. I think it would be better to explore and fix the underlying issue in the driver. If the driver is closed source then this is something that Beyonwiz should be able to organise / demand from its part supplier / manufacturer.

These band-aid solutions have a habit of coming back to bite people. A lot of my current coding effort is currently directed at fixing problematic band-aids used as quick fixes in the past.

Regards,
Ian.

[adoxa]

How many people would run without timeshift being enabled?

I'm one.

The USB tuner can still have an issue - tuner "mode-itis" can hit it; if you want a new mission then that could be it

I would, but I've not experienced it (I sometimes completely lose the tuner after a reboot, but have had no issues with restart).

While this patch appears to address the problem it is a bit of a hack. I think it would be better to explore and fix the underlying issue in the driver.

Sure, but considering this was first reported the start of last year, and has probably always occurred, I can't see that happening.

[IanSav]

Hi,

I wonder if the manufacturer has been contacted to get updated / fixed drivers? If this hasn't happened then it should be investigated as a matter of priority.

Given the small cost of USB dongles, particularly when you buy them in bulk, I think Beyonwiz could also look at finding a dongle that works properly and then offer a free swap out to get rid of all the problem tuners in the user base. This would eliminate the original issue and negate the need for a hack. The cost to Beyonwiz could be small particularly if the returned dongles are offloaded / resold for other uses. The goodwill would be enormous!

Regards,
Ian.

[Grumpy_Geoff]

...Did you try watching Live TV without timeshift enabled? I would have thought that the glitching would resume then.

I hadn't been watching the TV, but I had a spot check on a few of occasions and observed some bad glitching/image issues.
The log is devoid of errors, but adoxa's patch may prevent that.
The U4 driver has retuned due to 'lost lock' a number of times, and on one of the times it was at least 10 mins of pixelation before a retune.

We know the T2 and U4 identify the ITE Technologies 'DVB-T TV Stick' (ITE 9135 chipset) differently and use different drivers, as shown here.

[MrQuade]

Cool, that's as expected then.

[adoxa]

My fix/workaround/hack was just merged, so hopefully no one else will have to buy another tuner.