First Look: Dish Network's DTVPal Digital Converter

[A guy who read the manual]

Thanks!

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]

More on channel shifting in timers

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]

Oops, one prediction was wrong.

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. - :up
Just hope they get the fixes installed, and rolled out to customers before the next ice age! -


Then what? We start round two? -

 

[A guy who read the manual]

Revealing results from the last test

Well, I did the test with some very interesting results.

One of my assumptions was proven wrong, but only one.

One DTVPal hidden feature I thought would be hard to reproduce was reproduced.

(Have I built up enough suspense?)

First, reviewing what I planned to do:

I'll test to be sure it can be repeated: (i.e., to see if shifts can happen repeatedly)

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

I'll set 5 timers, then delete them all (learn why [STRIKE]below[/STRIKE] in the original post this is quoted from).

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.

Sorry it took more than an hour, but I decided to actually WATCH some TV first
. . . then some distractions delayed this posting of the results, even though the testing was done about 3 hours ago.

Anyway, here's what happened when I actually tried to complete the above:

Did the "set 5 timers then delete them all" thing.

Manually set the channel 29.2 timer for Mon-Fri, 9:29pm CDT, 12 min duration, 9:29pm to 9:41pm. Checked timer setting. Timer correctly said it was set for "Two and a Half Men" and the channel and time info was as expected.

(I didn't want to have to alter the Frequency, Start Time, or Duration; from the beginning, I set it for the time that I planned to be making a recording of the final results. And it worked out OK; those settings never changed, so I never had to edit them.)

Did the switch to TV Guide mode, rebooting in and rebooting back out. I let the Guide reload bar go the whole way, as I would do each time.

Checked timer. It now said channel 23.1, as predicted by the Before/After table, and timer correctly said it was set for "George Lopez" (no time change).

Did the double reboot as before.

Checked timer. Still 23.1! Hmm. . . 2 x shift can't be repeated after all! But let's try again to be sure.

Did the double reboot again.

Checked timer. Still 23.1!

OK. What to do now? Still have lots of time before the 9:29pm timer would trigger.

Edited timer, channel only. Changed 23.1 to 17.5 (next channel down). Then edited again, back to 23.1. (Left all other settings as is.)

Did the double reboot.

Checked timer. It now said channel 9.1, as predicted by table, and timer correctly said it was set for "Fox 9 News" (no time change). So editing the channel number had made the shifting bug possible again, as expected.

Did the double reboot.

Checked timer. Still 9.1! Confirms shift can't be repeated.

Edited timer, channel only. Changed 9.1 to 5.2 (next channel down). Then edited again, back to 9.1. (Left all other settings as is.)

Did the double reboot.

Checked timer. It now said channel 2.1, as predicted by table, and timer correctly said it was set for "American Experience" (no time change).

Now it was time to test how a "shifted channel," left unedited in the timer, would work. Would DTVPal turn on? If it did turn on, would channel 2.1 be the output, or was that a bogus number, and channel 9.1 would be the output, the way the timer had been set before the "shift"?

Set VCR to tape from 9:25 to 9:45, an extra 4 minutes before and after. It was now about 9:10. I watched a Boston Legal episode on DVD and waited. (By the way, there's something special about Boston Legal DVDs. They look almost as good as HD. Mmm, Rhona Mitra. . .)

Tape was recording, but light on DTVPal remained dark. Things did not look good. Except for Rhona.

Boston Legal and taping were both done. Lo and behold, there was stuff on the tape!

4 minutes black screen. NO starting 2 minutes early. NO countdown timer. NO "Now!" message. Then 12 minutes American Experience. On 2.1, the "shifted" channel! Then 4 more minutes black screen.

WOW. I had gotten results like this on tape just a couple of times before, and only on overnight tests. I had assumed the DTVPal had turned itself OFF in those rare results, because the picture had gone black on the tape, and the DTVPal light was off the next morning. I never imagined that the light had never come on at all!

So the DTVPal "stayed off" but sent out a picture that shut off at the end of the duration. This is using a composite connection to the VCR; nothing is connected to the RF output, so I don't know if there was any Channel 3 or 4 RF output.

Update, part 1: Although I'd looked at the VCR tape before I first posted this, I hadn't turned the DTVPal back on yet. Something interesting happened when I did.

The Guide download screen came on. Then I looked at the timer. It had shifted AGAIN, from channel 2.1 (0008) to channel 45.1 (0016). (Once again, I'm glad I am testing using "non-Once" timers; otherwise, the timer setting would have been gone.)

The important thing to understand here is that, although two shifts happened in a row, i.e., the subchannel got "reshifted," it was sort of a "new" timer setting. I had set the timer for 9:29pm Mon-Fri, starting Thu 7/10. Well, after it was triggered, it reset itself (in a sense) for 9:29pm Mon-Fri, starting Fri 7/11. That must have been enough to make the stored subchannel index "shiftable" again. And, that also may have somehow set up the need for the Guide to download when the DTVPal was turned on. (end Update part 1)

(If you're not interested in wild speculation and some less important details, you may want to skip to the last line of the post here. . .)

Is the DTVPal acting a little like it would in TV Guide mode? Not really. . . timers aren't even used in TV Guide mode assuming IR sent over the G-Link cable has the total responsibility for turning the DTVPal on and switching it to the right channel. But it's definitely in SOME special mode to operate like this. Maybe the "maintenance" mode (where channels are tuned on and off to collect PSIP data while DTVPal is "off") is taken over by the timer? Just a wild guess.

Is TV Guide mode involved somehow? Maybe. Lately I've been creating the bug by rebooting into TV Guide mode. It used to happen frequently without rebooting from July 5 to 7, but that was when WCCO, the local CBS station that sends digital TV Guide data, was failing to send PSIP, which somehow forced PSIP data to be downloaded for all channels (with the regular progress bar screen) each time the DTVPal was turned on. (I don't know whether the TV Guide data was also shutdown while the PSIP was shut down.)

Maybe some TV Guide version of the subchannel data is getting stuck into a timer event where a regular subchannel index should be. Maybe some TV Guide mode's field is one bit "wider" than the "normal" mode's field, and when the fields of a timer record are packed together, the subchannel index field gets shifted by one bit.

Enough guessing for now.

Tomorrow I'll be getting some cable that may improve my reception enough to change the way my DTVPal operates. (Then the guessing can begin all over again. )
MINNEAPOLIS, MN, US . . 07/10/2008 . . 11:19 P.M. . . ARRIVAL SCAN
ONTARIO, CA, US . . . . . . 07/08/2008 . . . 4:07 A.M. . . DEPARTURE SCAN
(UPS Ground. No stops in-between! That's a long haul!)

IF it was easy to get the DTVPal timer to work in this "off" mode, it would be as good as turning itself off at the end of timer durations, which a lot of people would prefer for unattended recording. But so far, to get the DTVPal to do this "off-mode timer operation," it looks like you have to be able reproduce my bug, AND you have to figure out what each of your channel shifts will be (like I did), AND the channel you record has to be one of the "After" channels (only half of your channels can be "After" channels), AND you have to intentionally set your channel to the "Before" channel that will shift to your desired "After" channel, AND then you have to force the shift. At least you wouldn't have to worry about it shifting again, because now we know it won't. Update, part 2: Although the channel won't shift again BEFORE the timer is triggered, a recurring timer (Daily, Weekly, or Mon-Fri) CAN shift again AFTER it has been triggered. So a Daily timer could keep shifting and a different channel would be recorded each day (assuming the bug happens daily, or is forced to happen daily) until the channel was shifted out-of-range and the timer goes blank. Still not sure if that "ghost timer" would do anything. . . But I could do another test. . . (end Update part 2)

Anyway, I think both "timer channel shift can only happen once (but then again after timer has been triggered)" and "DTVPal timer can work while DTVPal appears to be off" are BOTH pretty interesting new developments.

 

[A guy who read the manual]

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. - :up
Just hope they get the fixes installed, and rolled out to customers before the next ice age! -


Then what? We start round two? -

The thing is, it's repeatable for me, but not for pabeader. The difference is in the broadcasts we're receiving. DTVPals apparently work fine with no bugs (at least no timer bugs) if you are getting strong signals and good PSIP on all channels. The CBS affiliate in each market seems to be especially important, but that came to my attention because mine sent no PSIP at all for a 3-day stretch.

 

[A guy who read the manual]

"Bug-B-Gone" = "Take Off, Hoser" ?

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.

I think I sort of agree with you, but I still see it as only the copies of the "subchannel index" that are entered into the timer table that are getting "hosed." I think any other instances of the "subchannel index" values that are being used elsewhere in the DTVPal are not affected by this bug, or much more would be going wrong. My tables were never intended to indicate that the whole set of values is getting "hosed" in one shot. You enter 1 to 5 channels from the Before column into the timer, the bug "hoses" the index values entered into the timer, and what comes out, still in the timer, are the 1 to 5 corresponding subchannels in the After column (or, if it's an invalid index in the After column, the timer is not displayed or erased).

I see a timer event record as holding only 4 things:

1. Frequency (stored as a numerical code; Once(186-day range)/Daily/Sun/Mon/Tue/Wed/Thu/Fri/Sat/Mon-Fri is 195 possible values, so it could use as little as 8 bits, but let's say 12 bits so we can store an actual date for the Once option)
2. Start Time (1440 minutes in a 24-hour day, so it could use as little as 11 bits)
3. Duration (000-999 range, requires 10 bits)
4. Subchannel (I don't know if anyone will get over 128 subchannels, so that'd be 7 bits)

Grand total: 40 bits (5 bytes) is all that's required for a timer event record if you really need to conserve space and pack in the bits. But with only 5 events, and modern memory pricing, I doubt the designers were that stingy.

However, I suppose it is theoretically possible that the timer has a "copy" of the whole array of subchannel indexes, and through an extra level of indirection, an field in a timer event points into this array, and then that array, in turn, holds a pointer into the actual subchannel data. I don't see the need for this extra level of indirection, but if there is a "link list" like this between the timer array and the subchannel array, then it's possible that one column of that two-column "middleman" link-list array gets "hosed" all at once from the bug.

(It's pretty hard to talk about programming issues in such general terms when I don't even know what programming language or operating system we're talking about. But at least "hosed" is a nice general term that works for all systems )

Additional thought: Your relational database comment is a good one. When you learn the theory for relational databases, they teach you that any unique field will do as a "key" field to be used as an index into a table. For example, in a table of Screen Actors Guild actors, each has a unique full name (a union rule), so that could be the "key" field, in theory. But in practice, you wouldn't want to use anything as cumbersome as a full name string for a key field. You'd use something just like we've been talking about for the "subchannels index," simple serial numbers, preferably consecutive, for the key field. These serial numbers (still akin to row numbers in a spreadsheet, as was said a long time ago) don't get displayed in any database output, but they serve as an index into the table of Actors, and would be used as a links in other tables. Suppose there is also a table of American Movies, and each movie also has a serial number. Then other tables, maybe one called "Movie Credits," could have fields for Actor and Movie, and the entries into those two fields would just be the pair of serial numbers that pairs an Actor with a Movie.

 

[A guy who read the manual]

Taking a break today

I will be taking a break from this today, just waiting for UPS to show up with a couple hundred feet of RG-6 Quad Shield cable, a new co-ax stripper, a new crimping tool, and 50 crimp-on connectors.

No, I won't be re-cabling the whole house immediately. Some of it will take awhile.

But before I started this break, I updated a few of the posts above.

See you . . . around . . . . . . Never say "Never". . . ( link )

 

[Smith P.]

Should all threads about the PAL moved into OTA forum ?

 

[Malouff]

A guy who read the manual,

Test
Have you tested setting multiple timers all to a channel that does shift
Timer 1 - 29.2 timer for Mon-Fri, 8:59pm CDT
Timer 2 - 29.2 timer for Mon-Fri, 9:29pm CDT

Possible Result 1
After Timer 1 fires do you get results like this after the shift?
Where it changed the channel only for timer 1
Timer 1 - 23.1 timer for Mon-Fri, 8:59pm CDT
Timer 2 - 29.2 timer for Mon-Fri, 9:29pm CDT

Possible Result 2
That or do you get results like this after the shift?
Where it changed both channels for the timers
Timer 1 - 23.1 timer for Mon-Fri, 8:59pm CDT
Timer 2 - 23.1 timer for Mon-Fri, 9:29pm CDT

 

[noremac]

Can the firmware be updated?

All this discussion of timer behavior and software bugs is curious, but the bigger question is: Is there any provision for Dish to update the firmware on boxes sold? If there is any, I assume it would have to be OTA since the box has no USB interface.

 

[A guy who read the manual]

DTVPal OTA Upgrades - Not for everyone?

All this discussion of timer behavior and software bugs is curious, but the bigger question is: Is there any provision for Dish to update the firmware on boxes sold? If there is any, I assume it would have to be OTA since the box has no USB interface.

Good Question. We've heard it both ways. The most reliable sources imply that there IS a way to do it over the air, but who knows if upgrades will ever be activated in your area?

Here's a thought: What if the "not field serviceable" or "will have to be exchanged" comments about the DTVPal are only temporarily true, or only true for certain areas of the country? DTVPal probably IS designed to be upgradable over the air -- as I said, people who should know have implied that it is ( link ) -- but that could still only happen where DISH has made the necessary arrangements.

So the question is, if you find you're 150 miles out of range of a station that is broadcasting updates, do you get in your 50-mpg hybrid and take your DTVPal, power inverter, antenna, and portable TV on a road trip to snag a free upgrade, or do you go through the ship-it-to-DISH process?

Or, would you rather mail your DTVPal to a friend in an "upgrade city" than deal with DISH, even though you'd probably have to pay shipping both ways?

If the arrangements are ever made to send upgrades over the air, I'm lucky enough to live in a city where it's likely to happen. There's a CBS-owned-and-operated station here, which seems like a likely candidate since they're already sending digital TV Guide data. There's no sign of a software update on my DTVPals yet, though.

 

[A guy who read the manual]

Hmm. . .

A guy who read the manual,

Test
Have you tested setting multiple timers all to a channel that does shift
Timer 1 - 29.2 timer for Mon-Fri, 8:59pm CDT
Timer 2 - 29.2 timer for Mon-Fri, 9:29pm CDT

Possible Result 1
After Timer 1 fires do you get results like this after the shift?
Where it changed the channel only for timer 1
Timer 1 - 23.1 timer for Mon-Fri, 8:59pm CDT
Timer 2 - 29.2 timer for Mon-Fri, 9:29pm CDT

Possible Result 2
That or do you get results like this after the shift?
Where it changed both channels for the timers
Timer 1 - 23.1 timer for Mon-Fri, 8:59pm CDT
Timer 2 - 23.1 timer for Mon-Fri, 9:29pm CDT

Hmm. . . Interesting question.

The timers do not shift immediately after they have been triggered, only after some bug triggers an unnecessary extra download of Guide data (usually complete with the progress bar screen).

So the first part of the answer is that you would get neither result after the first timer was triggered; both would still say 29.1. But if I force a shift error after the first timer has triggered, then look to see what has shifted, I'm not sure which result I would get. I'll have to test it and get back to you.

On the other hand, here's a test where I could predict the results:

if I first set both those timers to 29.1, then forced a shift before either one had triggered, they'd BOTH switch to 23.1. Then, after the earlier one had triggered, if I forced a shift yet again, the previously triggered 23.1 would shift again to 9.1, but the other 23.1 timer (that hadn't been triggered yet) would stay at 23.1. (The no-additional-shifts-until-after-being-triggered rule.)

 

[rperlberg]

All this discussion of timer behavior and software bugs is curious, but the bigger question is: Is there any provision for Dish to update the firmware on boxes sold? If there is any, I assume it would have to be OTA since the box has no USB interface.

I have an idea for how software updates could be done without having to rely on the availability of an OTA broadcast. The vendor could distribute a DVD containing a video signal with the embedded software update data. Then, if the box was designed to accept OTA updates, you could just play the DVD into the box. One problem with this is that most DVD players don't have RF converters and it would be a bit much to have to buy an RF converter just to perform this operation, so another possibility would be if there were a mode you could put the box into that would cause it to temporarily go into a "read" mode on one of the A/V output jacks and you would connect the video output of your DVD player to that. You could monitor the operation from the RF output, or if they used an audio jack for the temporary video input you could monitor from the video output as well.