First Look: Dish Network's DTVPal Digital Converter

[A guy who read the manual]

Thanks for the support, T-Rat, pabeader, and Whidbey.
(You OK with the nickname, TalkingRat?)

No response from avsforum yet, other than the automated response which was sent around 6AM CDT.



(When I say "around," I mean

Thu, 10 Jul 2008 06:00:02 -0500

)

I only got ONE automated response, even though I sent the correction follow-up (see post #497). I hope their spam filter isn't dumb enough to kill both messages after I sent the corrected version.

But it's only been 9 hours, so I wasn't really expecting anything yet.

[Malouff]

A guy who read the manual,

Why does your Kitchen DTVPal and the HDTV/VCR DTVPal have a different channel map?

Rammitinski offered this bug to try and test.
If you want to experience a real good one, after you've tailored the channel list to your liking, try re-scanning for new channels and you'll have a real blast of a time dealing with the results.

[A guy who read the manual]

It isn't the timer that is actually messed up. It's the "channel name" that is associateed with the timer maybe. That seems to fit. (<--1) Think of two linked tables. The timer table has a link to the channel table. During a rescan, the channel table goes through a change that the timer table is not tracking correctly. (<--2) You aren't loosing timers, your loosing/shifting the channel that is associated with the timer. When you run out of channels you are in effect, "deleteing the timer"

DUH! I guess it was too early in the morning for me when I started this. You actualy said that already... well almost anyway.

I really think it's more a problem with the channel table rather then the timer table. (<-- 3) I bet if we check, the timers are still in there. Just no way to get to them anymore... Kinda like when you delete a file on your hard drive. It's still there, you just can't get to it in the regular way. (<-- 4)

I see you've been editing this since I read it last, as you've noted in the other quote below. I've added numbers to your points so I can comment better.

(1) No, the channel actually changes in the timer. When a timer altered by this bug is triggered, it WILL tune to the "After" replacement channel. This happened on a few of my overnight recordings. I was also able to look at the timer settings after it triggered, because I started using Mon-Fri, Weekly, or Daily timers for every test so the timer would still be there after it triggered. (And so, when the timer disappeared, I'd know it was due to the bug, not due to proper behavior like when a "Once" timer is triggered and disappears.)

Also note that this is TOTALLY predictable. If I set the timer to the channel in the "before" column, then force the bug to bite, it ALWAYS changes to the channel in the "after" column.

(2) The bug doesn't happen when channels are being scanned to build the subchannel table (also known as the Channel List, albeit re-sorted there by descending 000-00 numbering), or when channels are added or deleted (although those actions would certainly change the subchannel table and could affect timers.) The bug we're talking about happens when Guide data is reloaded due to another bug that causes it to happen everytime the DTVPal is turned on (that bug disappeared for me when CBS affiliate WCCO fixed its PSIP), OR the bug happens when I do 2 forced reboots by going into TV Guide mode and back out. As far as I can tell, there's no altering of the Channel List during this process, or during the downloading of Guide data that follows. In fact, the subchannel table, as already built, is what would be used to determine which stations should be scanned for PSIP data to rebuild the Guide. (Although there could also be a shorter "channel table" -- you don't have to load PSIP from every subchannel, only once per channel, so there may also be a hidden short list of "channels" without the "subs" that is used for this "where to look for PSIP" purpose. But if so, I still think BOTH the "channel list" and "subchannel list" are OK and are unaffected by rebooting and downloading Guide data.)

(3) No, I'd guess that the subchannel table (a.k.a. Channel List) is ok; if that was getting altered it would cause all kinds of other problems. Note that the relationship between the index and the channel number is the SAME in the Before column and the After column. For example, using the Kitchen DTVPal columns, 9.2 is at index 0010, and 41.1 is at index 0020, in BOTH the Before and After columns. But 9.2 (0010) Before becomes 41.1 (0020) After (after the bug has affected the timers). The index into the subchannel table, stored in the timer table, is what is experiencing the alteration.

I'll test to be sure it can be repeated:

This time I'm using figures from the HDTV/VCR DTVPal table. . .

I'll set 5 timers, then delete them all (learn why below).

Then, I'll set a timer to channel 29.2 (029-02, index 0001), force the bug, and it should change to 23.1 (023-01, index 0002), force the bug again, and it should change to 9.1 (009-01, index 0004), force the bug again, and it should change to 2.1 (002-01, index 0008). As I said, totally predictable. Then I'll turn the DTVPal off, and let the timer trigger, and confirm it switches to 2.1. Throughout this whole test, I'll leave the DTVPal tuned to a channel that is not involved in the timers above, say 41.1. . . .Oh boy, already did 20 reboots to construct the tables, now 6 more But that'll confirm the heck out of this! I should have results within an hour after I post this. UPDATE: Results are in, with a few surprises. See new post below.

(4) This is a very good point, and ties in with what I started rambling on about in the last PM I sent you (hadn't read your post here yet!) [To other readers: Here's the relevant part of that PM from 2PM CDT-- ". . .the timers are working well (now) if they are not too far out in the future, but now I have started to have the random turning on and off problem, which I never noticed before. Perhaps because I left an altered channel sitting in the timer? It shows the "wrong" channel and correct time, but maybe when the channel was altered, timer behavior was also altered in a way that isn't displayed. . . hmm. . . Although I think I've read the random on and off is happening without ANY timers set, so that works against my theory. . .]

You get the message "No Timers Set," I think, appearing in the top timer slot when the bug erases all timers (or do you just get 5 blank slots? I'll have to test that, too). But even so, there could be remnants of timers sitting around, not displaying themselves, causing these "random" on and off incidents. It's amazing how many of these bugs may be linked to each other, one bug setting up a condition that causes the next bug, over and over.

please watch thread post 496 as I think this through. Anybody have other thoughts??

A guy- here is a question... after the 'shift' does 23.1 have the timer settings from 29.2? I seem to remember from previous posts, that it does. (<--5)

hope things get straightened out over at the other place.. I can't even go there from here at work...

(5) Yes, although the channel number and name change from 029-01 29.2 WFTC (index 0001 on HDTV) to 023-01 23.1 WUCW-HD (index 0002 on HDTV), the time, frequency, and duration settings do not change, and as far as I can recall, the altered timer will always still work, and at the correct time, but just change to the "wrong" channel. But let's be clear about "wrong" here. The channel has been changed in the timer by the bug, but then when the timer is triggered, the DTVPal DOES change to the channel currently shown in the timer list. So in that sense, it changes to the "correct" channel.

In the cases where a timer disappears, I've been saying it was "erased" or deleted, but maybe it is just "undisplayable" as you've suggested, still hiding in memory somewhere. And maybe its start times and durations were altered (due to the shifted channel index going out-of-range, maybe). There's no way to tell without more access to the DTVPal's inner workings.

Some people might be thinking "This could only explain times when the DTVPal randomly turns ON, not when it turns OFF, because the timer doesn't ever turn the DTVPal OFF at the end of the duration." But that's not true, because I have recorded (literally recorded, on VHS tape) two times when the DTVPal DID turn OFF when the timer was done. So the capability is hidden in the box somewhere. Of course, that's two times out of many dozens of timer tests I've done.

PROPOSED TEST for anyone who is having lots of random ON and OFF events:

1. Set all 5 timers. Details don't matter, you'll be deleting them (just avoid timer conflicts so you can set all 5).
2. Select all the timers (you can mark them all with "blue blob" checkmarks), then select Delete.
3. Watch to see if your random ON & OFF problem is alleviated. (Don't set a timer until you've given this a good test, because setting any timer could potentially bring the problem back.)

The idea is that if there are "invisible timer ghosts" hidden in the DTVPal, you can force them out by filling up the timer slots. Then, deleting the timers means you should truly have "No Timers Set."

[A guy who read the manual]

Why does your Kitchen DTVPal and the HDTV/VCR DTVPal have a different channel map?

The same channels are there, just in a different order. The answer to your question is found in Note 1 and Note 1a, in the table image, just below the tables.

I was actually lucky I had the bad reception on the HDTV/VCR DTVPal, because having different channel maps made it easier to figure out the Before and After tables. It did take 20 reboots to map all the channel shifts, though. 5 groups of channels [max. 5 at time] x 2 DTVPals x (1 reboot into TV Guide mode + 1 reboot back out) = 20 reboots.

Now I'm off to do 6 more reboots for the test I described in the post above.

[Malouff]

A guy who read the manual,

Have you also got anything like Rammitinski?

When he deleted some of the unwanted ones and does a re-scan, it turns some of the ones you turned off back on, and also erases some of them.

This sounds very much like what you are testing with the channel table getting corrupted.

[pabeader]

The same channels are there, just in a different order. The answer to your question is found in Note 1 and Note 1a, in the table image, just below the tables.

I was actually lucky I had the bad reception on the HDTV/VCR DTVPal, because having different channel maps made it easier to figure out the Before and After tables. It did take 20 reboots to map all the channel shifts, though. 5 groups of channels [max. 5 at time] x 2 DTVPals x (1 reboot into TV Guide mode + 1 reboot back out) = 20 reboots.

Now I'm off to do 6 more reboots for the test I described in the post above.

Holy Cr@p!! I didn't realize that the shift you are seeing is repeated each rescan. I had no idea that what you were showing us was the labor of 20!! reboots. I thought it was all from one!! No wonder my ideas were not more on the mark. One thing to note: Going into and out of TVGuide mode should erase all timers. The fact that it doesn't worries me.

[A guy who read the manual]

Holy Cr@p!! I didn't realize that the shift you are seeing is repeated each rescan. I had no idea that what you were showing us was the labor of 20!! reboots. I thought it was all from one!! No wonder my ideas were not more on the mark. One thing to note: Going into and out of TVGuide mode should erase all timers. The fact that it doesn't worries me.

Turns out the shift is NOT repeated with repeated reboots & Guide downloads. That was the one assumption I had wrong. I had entered new channels into the timers for each of those double-reboot tests, so I guess I had never tried to "double" or "triple" shift a channel before. Details will be 2 posts away, after I respond to Malouff. I think you'll find the next two posts very interesting.

(If I didn't make it clear before, since there were 24 channels on each DTVPal, and I could only force the "shift" onto 5 channels at a time to find out what the "After" channel was for each, it took 5 "shifts" for each DTVPal, which was 10 reboots for each [5 into TV Guide and 5 back out]. 20 overall.)

[A guy who read the manual]

A guy who read the manual,

Have you also got anything like Rammitinski?

When he deleted some of the unwanted ones and does a re-scan, it turns some of the ones you turned off back on, and also erases some of them.

This sounds very much like what you are testing with the channel table getting corrupted.

Definitely a bug, but a fairly easy (but possibly tedious) workaround should be to (1) Either do a factory restart, or delete ALL channels (2) Rescan and add channels until all have been located (3) Only THEN, after all channels are present, delete the unwanted ones.

What you're talking about probably DOES involve getting the subchannel table corrupted, at least in some sense. On my Kitchen DTVPal, I had deleted 41.1-41.4 and added them back, and deleted 4.1 and added it back, but they ended up back in their original slots in the subchannel table. It sounds like I was lucky.

The bug I'm talking about right now doesn't involve corrupting the subchannel table exactly. I'm beginning to think it involves getting bits of TVGOS data formatting stuck into the non-TVGOS timer. So this bug is still an issue of corrupting some sort of timer table, not the subchannel table. More on that in the next post.

[pabeader]

a guy- your post is way too detailed for me to quote properly. I can't shake the feeling that the timer channel glitch is a linked list issue. I still can't see why it's happening but here is what it looks like to me. I know I said this already, and you have done a great job rebutting me. I think I might not have properly stated my case so...

When I look at the tables this is what I see. I am not looking at the actual channel number (29.1) I think of it as an index to another table. So for example, 29.1 might be index 0 in the "channel name table" 29.2 is 1 and so on. so in the timer table you would have a series of piecies that make up the whole timer. One of the pieces is "channel index", another piece would be "start time", "start date" etc typical relational database stuff.

during a rescan of the EPG data, unfortunalty, the "channel index" is being hosed. It's the "channel index" number that is getting "left shifted" that is why for you, timers that used to have channels above 12 disappear. you only have 23 entrys in the 'channel table' when the timer tables' "channel index" gets shifted, there isn't a corresponding entry to link back too. I bet that if I could recreate the issue, since I have only 9 channels, my timers would disappear after the 4 entry.

I tried to do this tonight, but my wife decided to go to bed early.

[Anole]

Don't let me interfere with the research, arguing, discussion, brainstorming, et al, but . . .
You've got a repeatable and documented failure, so exactly WHY it fails is no longer much of a concern.
With the info published above, the Dish engineers (do they hire from India for that, too?) can look into the code and find the error(s).
Plus, they already had an undisclosed laundry list of bugs . . .

A tip the hat to all concerned. -
Just hope they get the fixes installed, and rolled out to customers before the next ice age! -


Then what? We start round two? -