The Official AVS Dish DTVPal DVR Topic! - Page 511

Back when I was investigating this issue I recorded "Sunday Night Football" on NBC. On playback I was able to toggle between English on ENGLISH and Spanish on UNKNOWN. I also recorded a cartoon on FOX and I was able to toggle between English on ENGLISH and descriptive audio on SPANISH.

Pete's got it right. It records both tracks. If the DVR records the full digital signal as sent by the station, how could it not record the alternate audio tracks?

Proof: http://youtu.be/DRCwMKV9XwU

Correct. But only this one time. I've been recording them back to back for over a month.


It wasn't a repeating timer but one created on the fly by pressing the 'record' button on the Pal - once for each show. It's a mystery . . .

If I had a video camera, I would show that is not the case on my machine.

1. Bad recording: English = no voice (just background) Spanish = no voice (just background)

2. Good recording last night: English = full audio. Spanish = full audio.

Playback would not toggle the SAP channels. Live did toggle them. 208FW BTW. Maybe it has to do with the fact that it's playing on an old 20in CRT (down-converted signal) not a fancy flatscreen? Trying to be creative here . . .

Sounds like a glitch I had in one of my DVRs where it recorded the Spanish audio for a Packers game, even though as I watched the game live the audio was in English. No matter what settings I tried to change on the DVR and TV, it would only play the recording back in Spanish. Same thing happened a couple of times on the Simpsons and other Fox programs. Maybe it is a network or TV station corruption fault, and nothing to do with the DVR.

Appreciate your creativity but I can't see why the display would matter for sound. Multiple users have now confirmed the Pal does record all audio programs, although you may not be able to select between them if they're both labeled English

I assume you're using either the analog L/R audio outputs or the RF output. Maybe there's a difference when using HDMI or the digital audio output? Wouldn't be the first DTVPal bug we've found

I believe you now. But if it recorded the full digital signal, it'd record every subchannel being broadcast by the station being recorded (not to mention any null packets broadcast), and you wouldn't get more recording time when recording SD subchannels than HD ones. It'd always use up 19.3 Mb/s no matter what you recorded.

(Digression: the ability to do that could be an advantage in some cases. You could record more than two shows at once as long as they were all broadcast by two stations.)

So clearly it does filter the data stream, at least to get down to the subchannel you want to record. It seemed plausible that it'd also filter the audio programs.

What's weird is that, since it does record all the audio programs, and since his PBS station labels them with different languages, golinux still couldn't listen to the English program. I'm wondering if it'd work using a different audio output than whichever one he's using

This kind of speculation can continue indefinitely without resolution. The only way to make a conclusive analysis is to record a program containing the problem on both a DTVPal and another DVR or HTPC for the purpose of comparing the recorded files.

I think you may be on to something. Using composite (red, yellow, white) connectors not HDMI.

Unfortunately the DTVPal uses a proprietary file system. Without a driver for their filesystem there's no way to compare its recorded files with another device.

I'll see if I can play with it this week. If I can find a recorded show with multiple audio programs, I'll try playback with both analog and HDMI and see if I can select the alternate audio using each input. Your "lost" audio might still be in there somewhere

That was my understanding as well, but doing such a direct comparison is not strictly necessary to obtain the required information. If you find a recording that won't play SAP correctly on the DTVPal, you can examine solely the copy from an alternate DVR to potentially determine the cause. If both English and Spanish are present but mislabeled, you know that it's the DTVPal's fault that it can't detect both streams and the station's fault for not marking them correctly. If SAP isn't present or is being broadcast as the main audio, then the problem lies solely with the station.

No need. I FINALLY got it to switch SAP channels. It seems I was too impatient. There is a significant time lag between choosing the Spanish setting and having it kick in. I had already deleted my original problem recording. But I got a more recent one that was recorded correctly to switch back and forth between the two channels with the expected results.

I did play with it late last night and discovered the same thing. I found a show where the English and Spanish programs were different (actually the Spanish was mostly silent, except for a few commercials), hit record, then went back and played the recording, hit pause and switched back and forth. It would stay on the original audio for a few seconds, then switch. Apparently it reads the audio into a buffer, and only honors the switch when it has to go back to the recording to fetch more audio.

So now we know:
1. The DTVPal does record all audio programs, so you can switch between them during playback; BUT
2. You can only switch by language, so if your stations broadcasts two audio programs but labels both of them English, you're SOL; and
3. There's several seconds of buffered audio, so if you switch during playback, the change won't take effect immediately.

It just arrived last night. Works perfectly, and the upgrade went smoothly, thanks to the folks on this forum who figured out how to open the Pal's case Amusingly, once I got past all those crazy latches and unscrewed the drive cradle, there was a "tampering voids warranty" seal taping the old drive to the cradle Of course there was no warranty on this used unit, so I didn't let that slow me down.

Now I have a spare Pal - and a spare 250 GB HD Turns out 1 TB is a lot of storage: enough to record about 5 hours of HD every day for a month!

BTW has anyone compared actual recording time to the estimate shown on the My Recordings page? Since the Pal records the data stream from the station, I suspect YMMV depending on how much bandwidth the station gives whatever channel you record.

One of my local CBS stations has no sub-channels and a 1-hour HD program actually uses 1 hour and 10 minutes of HD recording time according to the DTVPal DVR. I have another local CBS station that has 1 sub-channel and a 1-hour HD program on that station's main CBS channel uses just about 1 hour of HD recording time according to the DTVPal DVR. I found this out by how much HD recording time is put back in the available HD recording time when I have deleted previously-recorded HD programs from each station. As you stated YMMV.
Edited by trp2525 - 12/13/12 at 7:27am

Has it been determined whether the 'Pal will still search for new channels overnight when it's turned off in standby mode, if the "Updates" function is disabled?

I do not like turning on a 'Pal in the morning to find new channels added that were coming in from atmospheric conditions for a short time overnight. So I usually just leave them both on. Not a lot of difference in power usage between standby or on modes.

Yes it will. The updates function is only for obtaining firmware updates. (BTW there has not been one since July 2009 when F208 was released.)

And as far as I know there was never a way or source for it to obtain updates. Always had to do it with a download to a mem stick into the USB in the back, right?

My Sony TV has "UpdateTV" and once in the past 5 years it did actually get an over-the-air update. Made me very nervous when I turned on the set expecting just the usual, and it put up a screen that it was installing and do not interrupt power or disturb the process. I took that to mean I could end up with a screwed-up TV if all didn't go well.

I hate doing firmware upgrades. Things can go wrong and brick them. Software upgrades aren't so bad since we usually can uninstall and reinstall.

I don't think that is correct. I remember that those who had their DTVPal DVR hooked up to the internet with an Ethernet cable would get the updates when they were released and would actually get them before they were released on the DTVPal website for download to a USB memory stick. When the DTVPal DVR was initially delivered back in December 2008, some owners hooked up their DVR immediately to the internet via Ethernet and were immediately updated. There was already an F202 firmware update (to update from the original F201) as the very first units started to arrive at people's homes via UPS.

BTW the only firmware updates that were released to the public were F202, F206, F207 and F208. I believe the "missing" firmware versions were used by Dish/EchoStar for troubleshooting and software-development purposes.

That's what I was expecting. CBS owned/operated stations don't run subchannels; except for low-bandwidth services like TVGOS the entire data stream is used by the single HD channel. So they give the highest-quality HD, but it uses up disk space more quickly. Stations with one subchannel (and Fox O/O stations and affiliates, for boring technical reasons) are probably pretty close to the Pal's estimates, while stations with tons of subchannels and the few stations in the US running dual HD probably use the least space (at the expense of picture quality, of course).

Disk usage might even vary between different programs on the same channel, especially if the station runs other subchannels. Many stations use a statmux that reallocates bandwidth among their subchannels dynamically, so a football game with lots of fast-moving scenes would use more disk per hour than, say, golf.

That could be useful knowledge for those lucky enough to live near two affiliates of the same network. One may give you better-quality video, while the other may be best if you're running low on disk space.
Edited by JHBrandt - 12/13/12 at 1:42pm

Totally agree. Any device with upgradable firmware should have enough space for two copies and an A/B switch, so you can always boot from a known good copy in case the power fails during an update.

You are correct.

Contrary to these instructions from the first post, you can also use 01 for the address. Remember, the instructions were intended to resolve conflicts between the Pal and another device using Dish remote codes, which would probably be set to address 01. The idea was to ensure different devices had different addresses so the remotes wouldn't operate the wrong devices. There's nothing inherently wrong with address 01.

And there's one case where you should use 01 for the address: if you want to control the Pal with an inexpensive "universal" remote (and you don't have another conflicting device). Most cheap remotes can only operate Dish devices if they're set to address 01.

For the past several days, while having my morning cup of coffee, I have been logging some of the DTVPal diagnostic data related to time calculations. Not many conclusions about the time calculation algorithm. What I can say is:

Time calculations for local stations are accurate, however I do have at least one instance were the DTVPal calculated time did not agree with PSIP time (for two days).

The engineer at WRBA knows about his PSIP time error. He has fixed it a couple of times and after a week or two the error returned

WDBJ got a new PSIP system about a year ago. Since then their clock has been off by 16 seconds

On my DTVPal, if a station is not being received it's clock will advance 9 seconds a day.

DATA ATTACHED: TVGOS.xls 25k .xls file

On line 27 you can see a couple of large changes at WBRA on Dec. 5 and Dec. 12. Is that where the engineer fixed the time and where the error returned later? Wonder if someone else at the station is messing with him

On line 19 you can see how the DTVPal made adjustments after those changes. It was pretty accurate during that week.

I'd bet that's the inherent error of your DTVPal's internal clock. That's over a minute per week or almost an hour a year.

Other DTVPal clocks are probably similarly inaccurate. Obviously that's only good enough for a few days before it needs to be resynced. Luckily it seems to resync at least once a day.

No. Those fixes occurred before I started taking data,. The station engineer is aware of the problem and could be working on it in his spare time. I did not independently confirm the DTVPal data in this instance.

But this error only affects "outliers" and should have a minimal impact on the time calculation.

I agree. Presumably inactive stations (typically flagged x'4404') are ignored (or at least down-weighted) in the time calculation since they haven't been resynced recently and would likely be off by some indeterminably large amount. The DTVPal's actual time error did not appear to be increasing steadily.

My assumptions are:

Inactive=0x2203
Active= 0x4404 which includes some "outliers"

I am checking to see if 0x4404 will go to 0x2203 at some point in time and/or if one of the "outliers" will suddenly become accute.

Why aren't you guys going in droves to Rovi's facebook page and complain about TVGOS going away? This box will be severely impaired without TVGOS. Come on guys do something to help. Maybe if enough complain they(rovi) will do something