Click here to go to the forum index Click here for the home page
 
Author Message

<  Bugs  ~  A Mechanism for Poor Signal Crashes

Page 1 of 9
Goto page 1, 2, 3, 4, 5, 6, 7, 8, 9  Next
EMJB
Posted: Sun Feb 13, 2011 10:21 am Reply with quote
Frequent contributor Joined: 08 Jul 2005 Posts: 3639 Location: Maldon Essex
I think I may have stumbled across a, if not the, mechanism of poor signals leading to crashes or even disc wipes.

I have been running my Toppy with marginal signal levels for some time to try to find out what is going on, but nothing happened till yesterday when the signals were even worse than usual, and even then I had no problem till I did a rescan. After the rescan many of the channel names were garbled, and those on the weakest mux seemed to consist of all "FF" characters across the full width of the native Toppy channel display, and when I ran Channel Organiser it immediately crashed. On rebooting MyStuff immediately crashed the system, as did MyInfo when it did its stuff. However this morning, without any intervention on my part, the multiple "FF" channels had magically renamed themselves, and MS, MyInfo, & Channel Organiser all run OK. I am running firmware MS6 Recommended F/W 12/9/2009 -FmSy+C0CfCtFsHrHsPePsR0UUuZXl on this machine.

I was going to run a test TAP this morning to determine whether the crash occured within the TAP_Channel_GetInfo() or in the TAP as a result to the returned data being too long, but of course now the problem has gone away it is too late. Can anyone think of anything I can do now?


My theory as to what happened is as follows:

    (1) The signal quality at the time of the rescan was such that it was just good enough for the weakest Mux to be recognised, but poor enough to garble the channel name data on the weakest Mux.

    (2) The garbled name strings were too long, and so garbled other names. Furthermore they were such as to cause TAP_Channel_GetInfo to crash, or to return name strings that were unexpectedly long so as to crash any TAPs that used the data.

    (3) This morning, the Toppy started on a channel on the offending Mux, and the auto-rename logic renamed the offending channels with valid names, so the MS/MyInfo & CO alll ran OK. (The auto-rename logic updates the Toppy channel names without a rescan if the other channel parameters such as Service ID have not changed).
If the above interpretation is correct, then the inverse situation can presumably occur, i.e. the names can be good at the time of a scan, get garbled when the signal level degrades which will then cause a crash if a TAP tries to access the channel name before the signal improves enough to reset the name. The Recording header appears to contain the channel name, so a garbled name when the recording ends presumably could also lead to a crash.

If the above is what is actually happening, it is not surprising that it has not been noticed, as by the time the Toppy has rebooted & done its V&V, the signal may well have improved enough to correct the name , even if the Toppy owner thought to look at the channel names.

Unless someone can find a flaw in the above, we next need to consider what to do about it. the potential solutions would seem to be:

    (a) A patch to stop the long name strings being generated in the first place.

    (b) A patch to stop the auto-rename function

    (c) A (pretty trivial) TAP to set the "Do not auto-rename" flag (used to allow manually renamed channels to retain their new name) on each channel, but this would need to be rerun after each scan.
Comments please!

EMJB
View user's profile Send private message
alan_m
Posted: Sun Feb 13, 2011 10:40 am Reply with quote
Frequent contributor Joined: 18 Oct 2006 Posts: 3509
I suspect that my disk wipe caused when recording from a MUX that was losing signals. However, the other 5 MUXs at the time were rock steady and I don't recall the channels names or the EPG being corrupted.

Has anyone tried starting off a recording with a fully working Toppy/EPG/Signal and then disconnecting the aerial whilst recording? This could be another scenario for corrupt disks.

_________________
Ex Toppy 5800 user - now migrated to Extrend ET10000 Enigma 2 box with 2 terrestrial and 2 satellite tuners
View user's profile Send private message
EMJB
Posted: Sun Feb 13, 2011 10:49 am Reply with quote
Frequent contributor Joined: 08 Jul 2005 Posts: 3639 Location: Maldon Essex
If my theory is correct:

alan_m wrote:
I suspect that my disk wipe caused when recording from a MUX that was losing signals. However, the other 5 MUXs at the time were rock steady
Only the channel benig recorded need have the name affected, so the levels on the other Muxes is probably irrelevant.

alan_m wrote:
and I don't recall the channels names or the EPG being corrupted.
If it were only a glitch due to interference etc then it could well have corrected itself without you noticing.

alan_m wrote:
Has anyone tried starting off a recording with a fully working Toppy/EPG/Signal and then disconnecting the aerial whilst recording? This could be another scenario for corrupt disks.
Totally removing the signal would not lead to a rename, so I would not expect this to cause problems.

EMJB
View user's profile Send private message
ccs
Posted: Sun Feb 13, 2011 11:16 am Reply with quote
Frequent contributor Joined: 30 Oct 2007 Posts: 2587
alan_m wrote:
I suspect that my disk wipe caused when recording from a MUX that was losing signals. However, the other 5 MUXs at the time were rock steady and I don't recall the channels names or the EPG being corrupted.

Has anyone tried starting off a recording with a fully working Toppy/EPG/Signal and then disconnecting the aerial whilst recording? This could be another scenario for corrupt disks.
When I setup a crash trace to monitor poor reception, ending up with a wiped disc, I too only had one MUX with poor signals.

_________________
TF5810, F/W: MS6 Recommended F/W 12/9/2009 -FmXl+CtEzIScVdZ
TAPs: EIT Sub v0.6; EPG2MEI v0.96; MPDisplayLITE V1.2; MyInfo B5.6; SecCache (UK) v0.4; Extend v1.7; MyStuff 6.6;
Sig generated by MyInfo on 20/10/14
ccsx
View user's profile Send private message
EMJB
Posted: Sun Feb 13, 2011 11:20 am Reply with quote
Frequent contributor Joined: 08 Jul 2005 Posts: 3639 Location: Maldon Essex
ccs wrote:
When I setup a crash trace to monitor poor reception, ending up with a wiped disc, I too only had one MUX with poor signals.
According to my theory, that's all you need to get a crash.

EMJB
View user's profile Send private message
HydeTheDarkerSide
Posted: Sun Feb 13, 2011 11:24 am Reply with quote
Frequent contributor Joined: 11 May 2005 Posts: 5956 Location: Hannington Transmitter : Sony KDL 40Z5800
EMJB wrote:
alan_m wrote:
Has anyone tried starting off a recording with a fully working Toppy/EPG/Signal and then disconnecting the aerial whilst recording? This could be another scenario for corrupt disks.
Totally removing the signal would not lead to a rename, so I would not expect this to cause problems.

EMJB
This is correct. I used to perform an aerial disconnect as part of the firmware tests we used to perform on the releases coming out of Korea. Never saw any corruption or reboots.

_________________
Hyde.
[size=10:da1fd20a33][b:da1fd20a33]2x TF5800 All controlled with Harmony Ultimate [/b:da1fd20a33], TS On, F/W: MS6 Recommended F/W 12/9/2009 -RSy+BmC0CbCfCtDsEgEmEvFsGIMPePsR0ScUUuWfXZ
TAPs: PcControl B1.3; EPG2MEI v0.96; Font Manager 1.0d; Extend v1.7; SecCache (UK) v0.4; EIT Sub (Game) v0.6; MyInfo B5.6; MyStuff 6.5 RC2;
[color=blue:da1fd20a33]MyStuff Links: http://www.toppy.org.uk/~mystuff/index.shtml[/color:da1fd20a33]
Sig generated by MyInfo on 11/10/13[/size:da1fd20a33]
View user's profile Send private message Visit poster's website
ccs
Posted: Sun Feb 13, 2011 11:24 am Reply with quote
Frequent contributor Joined: 30 Oct 2007 Posts: 2587
This was the trace, but it was of no help at the time.

_________________
TF5810, F/W: MS6 Recommended F/W 12/9/2009 -FmXl+CtEzIScVdZ
TAPs: EIT Sub v0.6; EPG2MEI v0.96; MPDisplayLITE V1.2; MyInfo B5.6; SecCache (UK) v0.4; Extend v1.7; MyStuff 6.6;
Sig generated by MyInfo on 20/10/14
ccsx
View user's profile Send private message
EMJB
Posted: Sun Feb 13, 2011 11:35 am Reply with quote
Frequent contributor Joined: 08 Jul 2005 Posts: 3639 Location: Maldon Essex
ccs wrote:
This was the trace, but it was of no help at the time.
R2-D2 associated this with updating the .rec header, which seems to contain the channel name, and so is consistent with my theory.

EMJB
View user's profile Send private message
EMJB
Posted: Sun Feb 13, 2011 11:45 am Reply with quote
Frequent contributor Joined: 08 Jul 2005 Posts: 3639 Location: Maldon Essex
Somewhat to my surprise, BobD has indicated by email that MyStuff calls TAP_Channel_GetInfo "quite often" after initial setting up, so my suggested mechanism would explain apparently random crashes in normal operation for MS users.

Looks as if we need an input from R2-D2 or someone else familiar with the firmware to see if there is any check on the name length when extracting the name from te transmitted data.

EMJB
View user's profile Send private message
mstombs
Posted: Sun Feb 13, 2011 11:46 am Reply with quote
Frequent contributor Joined: 31 Dec 2006 Posts: 938
Great stuff - I have also had crash+VF&F when attempting to view a channel on a single poor reception MUX
View user's profile Send private message TF5800
Geoff Bacon
Posted: Sun Feb 13, 2011 11:59 am Reply with quote
Frequent contributor Joined: 12 Jan 2007 Posts: 4416
How about a patch that
1) checks the maximum length of a channel name and truncates it if it is too long
2) ignores any channel auto rename if it contains "invalid" characters or was too long
3) possibly ignores any auto rename if the mux quality is less than 97 (say)

The third test is probably an overkill as the first 2 tests will probably catch most cases.

Perhaps what we also need is a mechanism to prevent a recording starting on a poor quality Mux (assuming it is still ok to record on the other muxes). I don't know what one does if the quality deteriorates whilst the recording is in progress!

Geoff

_________________
TopManager program
TF5800, TS On, F/W: MS6 Recommended F/W 12/9/2009 -Sy+EvEzPfUUuZ
TAPs: PcControl B1.4; StopExit v1.01; PruneEPG 1.0; fsSave 1.1; QuickJump 1.72; SecCache (UK) v0.4; EIT Sub (Game) v0.6; EPG2MEI v0.96; MyStuff 6.6; Bookmark 3.0; Extend v1.7; Font Manager 1.0d; MyInfo B5.6; MHEG On/Off A3;
Sig generated by EMJB's MyInfo.tap on 29/12/18
View user's profile Send private message Visit poster's website
EMJB
Posted: Sun Feb 13, 2011 12:39 pm Reply with quote
Frequent contributor Joined: 08 Jul 2005 Posts: 3639 Location: Maldon Essex
Geoff Bacon wrote:
Perhaps what we also need is a mechanism to prevent a recording starting on a poor quality Mux (assuming it is still ok to record on the other muxes). I don't know what one does if the quality deteriorates whilst the recording is in progress!
If my hypothesis is right (still a big "IF" until the code bug is confirmed!!) then patching this bug should avoid any problems so preventing recording would seem unnecessary to me. For many people the problem may be sporadic interference rather than low signal level, so quality when the recording starts may mean little.

EMJB
View user's profile Send private message
BobD
Posted: Sun Feb 13, 2011 2:10 pm Reply with quote
MyStuff Team Joined: 03 Aug 2005 Posts: 4218
EMJB wrote:
Somewhat to my surprise, BobD has indicated by email that MyStuff calls TAP_Channel_GetInfo "quite often"
And to my surprise too. I'm going to cut down on some of them.

_________________
FW: ChunkyWizard Recommended
TAPs:
MyStuff (always one version ahead of everyone else!), and recommended support TAPS
MyStuff skins, manual and latest version: http://www.BobDsMyStuff.co.uk
Known bugs & forthcoming fixes: http://www.BobDsMyStuff.co.uk/Bugs.shtml
Changes coming in the next version: http://www.BobDsMyStuff.co.uk/NextVersion.shtml
View user's profile Send private message Visit poster's website
R2-D2
Posted: Sun Feb 13, 2011 3:59 pm Reply with quote
Frequent contributor Joined: 18 Dec 2006 Posts: 12148
Once [Nf] is installed there aren't any significant packets that have a CRC that isn't checked [there's plenty of code that looks like it might do that, but eventually it turns out that it's not used!!]. But in one of my notes against the filtering routines is "*BUG* does not free cpypkt on failure?". This is one of the sources of memory leaks that plagued non-turbo USB transfers (due to the EPG collection). The SDT (which define the channel names) might run into this issue if the system is getting clogged up with lots of partial sections (due to CRC failures). But I think it's much more likely that overall memory is the real issue. If you can, try running MemLog (or similar) to monitor what's happening there.

_________________
Troubleshooting -- User Manual -- Dark Side of the Matrix: Firmwares and Patches
View user's profile Send private message Visit poster's website
BobD
Posted: Sun Feb 13, 2011 5:56 pm Reply with quote
MyStuff Team Joined: 03 Aug 2005 Posts: 4218
I am planning on removing all calls to this function except on MS start (and in response to SuperZ1s etc) by caching the results. Half the time MS is already using cached results, and half the time it isn't, as a result of various layers that have been added at different times.

_________________
FW: ChunkyWizard Recommended
TAPs:
MyStuff (always one version ahead of everyone else!), and recommended support TAPS
MyStuff skins, manual and latest version: http://www.BobDsMyStuff.co.uk
Known bugs & forthcoming fixes: http://www.BobDsMyStuff.co.uk/Bugs.shtml
Changes coming in the next version: http://www.BobDsMyStuff.co.uk/NextVersion.shtml
View user's profile Send private message Visit poster's website

Display posts from previous:  

All times are GMT + 1 Hour
Page 1 of 9
Goto page 1, 2, 3, 4, 5, 6, 7, 8, 9  Next

Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum