Try a factory reset and wait 24 to 36 hours.

I think Trip in VA or someone else on the NY board has a schedule of when TVGOS comes over CBS. If I remember right it is 4 or 6 times a day. So it all depends when you reset or unplug box.

I can tell you my Aunt said she got it around 4pm yesterday

Hope that helpsActually, you said your aunt got it the afternoon of the 11th, not yesterday. Over on the Sony forum, some say they got it on the 11th too, but then it disappeared again by yesterday. Perhaps your aunt should go out to the 7th day and see if that is filled in or empty. WCBS may have just had it up temporarily.

No way to hack or use adapters/addons to use this DVR? I am moving and OTA is pretty much impossible due to the blocked hill side facing the transmitters even on the top of the house's roof. :(

Thank you in advance. :)

No way to hack or use adapters/addons to use this DVR?

No, it's for off air use only. There is no way to adapt/hack it, to make it work for anything else.

If (and that's a BIG IF) you can find a device that will output ATSC , you could use this on another source. The way it is designed - it only records from the ATSC tuners.

If (and that's a BIG IF) you can find a device that will output ATSC , you could use this on another source. The way it is designed - it only records from the ATSC tuners.That would be ATSC modulated on an RF channel 2-69 - never heard of anything short of a broadcast transmitter that outputs that!

Actually, you said your aunt got it the afternoon of the 11th, not yesterday. Over on the Sony forum, some say they got it on the 11th too, but then it disappeared again by yesterday. Perhaps your aunt should go out to the 7th day and see if that is filled in or empty. WCBS may have just had it up temporarily.

I still don't have it and I have tried every option to get it. I supect it may just be me and my location but since neither of my 2 PALs have received it I wonder if it has been up and down too.

No, it's for off air use only. There is no way to adapt/hack it, to make it work for anything else.Bummer. I might have to retire this OTA in a few months then. :(

Actually, you said your aunt got it the afternoon of the 11th, not yesterday. Over on the Sony forum, some say they got it on the 11th too, but then it disappeared again by yesterday. Perhaps your aunt should go out to the 7th day and see if that is filled in or empty. WCBS may have just had it up temporarily.

Ok not to confuse you anymore. I just spoke to her again and had her turn it on and had her push the forward skip button. Today is the Sat. 14th She can see all the way to Sat 21st.

I can only tell you what she tells me. I am not seeing this first hand. So I am assuming she is relaying the correct info.

Ok not to confuse you anymore. I just spoke to her again and had her turn it on and had her push the forward skip button. Today is the Sat. 14th She can see all the way to Sat 21st.Well, that indeed implies that it's up and working in her area (I'm assuming her TVGOS host could only be WCBS, right). Maybe it was up, then down, and now up again - otherwise I can't imagine why others saw it come on and go off, or never even saw it come on.

Well, that indeed implies that it's up and working in her area (I'm assuming her TVGOS host could only be WCBS, right). Maybe it was up, then down, and now up again - otherwise I can't imagine why others saw it come on and go off, or never even saw it come on.

Correct me if I'm wrong, but if it had been up for a day, filled the guides and went down again, wouldn't the TV Giode logo stay up till the data that was downloaded is all past?

So it could be down and yet folks still see the logo.

Correct me if I'm wrong, but if it had been up for a day, filled the guides and went down again, wouldn't the TV Giode logo stay up till the data that was downloaded is all past?

So it could be down and yet folks still see the logo.
I think the Sony boxes look for TVGOS 24/7 since it needs it to work. The DTVpal could work as you described.

So that is why I suggested we wait till tomorrow and I will ask her to look again.

If her Guide shows Sun to Sun then we know it is up and working. If it shows Sun to Sat. Then we know it is down and the DTVpal is working on just the info it got the other day.

[...]
So that is why I suggested we wait till tomorrow and I will ask her to look again.

If her Guide shows Sun to Sun then we know it is up and working. If it shows Sun to Sat. Then we know it is down and the DTVpal is working on just the info it got the other day.

If you are going to have her look again, there is an easier way to get to the end of the guide. When you bring up the guide, just enter the number of hours you want to go out, and then press the right arrow. The guide will jump to that spot. If I want to go to the end of the guide, I bring up the guide enter 200, and then right arrow, and I'm there (there is actually less than 200 hours of data, but 200 will always go to the end.

One more thing, if TVGOS went down three days ago, there would be no way to have data for next Saturday. Data for next Saturday was sent out for the first time over night, so if she has data for next Saturday that says TVGOS was up and running early this morning.

Also, and maybe this was implied, you said she was able to go out to next Saturday, but are you certain there was data out that far? It could have all been 'No Information'. Even if you only have PSIP data, you can still go out to day 7, but that doesn't mean there is data out that far.

Mark

If you are going to have her look again, there is an easier way to get to the end of the guide. When you bring up the guide, just enter the number of hours you want to go out, and then press the right arrow. The guide will jump to that spot. If I want to go to the end of the guide, I bring up the guide enter 200, and then right arrow, and I'm there (there is actually less than 200 hours of data, but 200 will always go to the end.

One more thing, if TVGOS went down three days ago, there would be no way to have data for next Saturday. Data for next Saturday was sent out for the first time over night, so if she has data for next Saturday that says TVGOS was up and running early this morning.

Also, and maybe this was implied, you said she was able to go out to next Saturday, but are you certain there was data out that far? It could have all been 'No Information'. Even if you only have PSIP data, you can still go out to day 7, but that doesn't mean there is data out that far.

Mark
I will double check tomorrow for ya:D

She would of told me No information. She hates those words lol

I will double check tomorrow for ya:D

She would of told me No information. She hates those words lolNow the Sony forum is saying it's back up again, so perhaps this time it's for good. Can KYW be far behind (I hope not!)

Now the Sony forum is saying it's back up again, so perhaps this time it's for good. Can KYW be far behind (I hope not!)

Do you get feed from ESB?

Do you get feed from ESB?Not me, I need to wait for KYW to come back up in Philly.

Not me, I need to wait for KYW to come back up in Philly.

Well once they figure out a fix. I would assume it would go faster

Still nothing at my house on either of my boxes.

Actually, you said your aunt got it the afternoon of the 11th, not yesterday. Over on the Sony forum, some say they got it on the 11th too, but then it disappeared again by yesterday. Perhaps your aunt should go out to the 7th day and see if that is filled in or empty. WCBS may have just had it up temporarily.

As of 10 am this morning I asked to check when I was on the phone. She still see's the Tvguide logo and has Information for the FULL 7 days.

Last night she had 3 days. During the day it was 7.

CBS must be turning it on and off

Still nothing at my house on either of my boxes.

LenL you said it was past 36 hours since you did a factory reset. I think you should do it again on both boxes


PS what is your CBS signal strength?

As of 10 am this morning I asked to check when I was on the phone. She still see's the Tvguide logo and has Information for the FULL 7 days.

Last night she had 3 days. During the day it was 7.

CBS must be turning it on and off

It just doesn't work that way. Just because CBS turns off the TVGOS doesn't mean that the guide data would instantly vanish from the DTVPal. If CBS turned it off after she saw 7 days of listings yesterday, it would not go back to 3 days of listings, it would still show 7 days of listings. Now if she unplugged and replugged the DTVPal, then she would only see PSIP data for about 10 minutes, before the TV Guide data was displayed again. Could that be what she did when she saw partial listings?

Mark

LenL you said it was past 36 hours since you did a factory reset. I think you should do it again on both boxes


PS what is your CBS signal strength?

As of Monday 9:30 AM no TVGOS. I even tried factory reset and unplugging. CBS signal strength is in the upper 90's on one box and low 90s upper 80s on the other box (fed by 2 different antennas).

As of Monday 9:30 AM no TVGOS. I even tried factory reset and unplugging. CBS signal strength is in the upper 90's on one box and low 90s upper 80s on the other box (fed by 2 different antennas).

I would call ppl who has ATSC PC tuner in your area to check what is in a stream.

As of Monday 9:30 AM no TVGOS. I even tried factory reset and unplugging. CBS signal strength is in the upper 90's on one box and low 90s upper 80s on the other box (fed by 2 different antennas).

When you say you did a factory reset, did you select the 'Factory Default' option from the menu, or just hold the power button for 10 seconds? holding the power button (or unplugging) is not the same as a factory reset.

Mark

When you say you did a factory reset, did you select the 'Factory Default' option from the menu, or just hold the power button for 10 seconds? holding the power button (or unplugging) is not the same as a factory reset.

Mark

I have done all 3. I had them unplugged for 5 plus hours, I did the soft reset using the remote and this AM I tried the Menu factory reset. I also tried doing a complete new setup. So far nada. I also have excellent reception for CBS. So it could be something unique to my location? I have not tried using the default 00001 zip for NYC as my local zip code has worked in the past.

I would call ppl who has ATSC PC tuner in your area to check what is in a stream.

I don't know anyone in the area with a PALDVR or a PC tuner. I have been thinking about getting a PC tuner for use in testing my antennas outside with my laptop but I never pulled the trigger. I do know other people using OTA for TV reception but not with any devices.

I don't know anyone in the area with a PALDVR or a PC tuner. I have been thinking about getting a PC tuner for use in testing my antennas outside with my laptop but I never pulled the trigger. I do know other people using OTA for TV reception but not with any devices.

Any digital TV has an ATSC tuner and a lot of TVs (at least some) are TVGOS enabled, at least I know Sony makes one. I expect the bigger challenge will be finding someone who also is using an OTA signal. Some place like BestBuy will have TVs with TVGOS but they will probably be connected to cable so you don't know where the signal is coming from.

I have done all 3. I had them unplugged for 5 plus hours, I did the soft reset using the remote and this AM I tried the Menu factory reset. I also tried doing a complete new setup. So far nada. I also have excellent reception for CBS. So it could be something unique to my location? I have not tried using the default 00001 zip for NYC as my local zip code has worked in the past.

Be sure you wait several hours (preferably overnight) before doing any more resets. The real 'Factory Defaults' should fix the issue, but you need to give the TVGOS several hours to load.

Mark

Very recently I've started having problems with some recordings. The picture will freeze during playback, but will let me use skip or fast forward (at any of 4x, 15x, 60x etc) - but when I try play again it will freeze. The last time it happened the problem cleared up about about 2 hours into a 3 hour recording i.e. it played back normally from the 2 hour mark. I've tried rebooting the machine and replaying the recording from the start but that doesn't fix it.

It has only happened with a few recordings so far - most are fine. I haven't noticed any pattern to it e.g. whether it happens for certain channels only, whether 2 recordings are happening at once etc.

I'm wondering if there could be a problem with a portion of the hard drive. Has anyone else experienced similar issues or have an opinion on the root cause of the problem?

If I need to replace the hard drive, does anyone know if the Western Digital WD10EURS model would be compatible? It's not listed in the FAQ as a recommended drive.

Thanks for any help...

Very recently I've started having problems with some recordings. The picture will freeze during playback
Bad reception during recording could cause that.

@mjrifkind,
Checking the HDD health would be beneficial for you and will help to next step troubleshooting: signal or the drive ?
Use free programs: MHDD (selfboot CD, USB) or Victoria 4.46b under Windows.
Run Scan with Remap=ON, but take SMART before and after that run.
Post all three logs here for final review.

Am I now the only person in America without TVGOS being seen by their PALDVR? Neither one of my 2 boxes fed by 2 different antennas pick it up.

Am I now the only person in America without TVGOS being seen by their PALDVR? Neither one of my 2 boxes fed by 2 different antennas pick it up.
Can we assume you know what station in your area broadcasts TVGOS,
and that you've talked to the engineer(s) at that station?

Can we assume you know what station in your area broadcasts TVGOS,
and that you've talked to the engineer(s) at that station?

CBS NYC 2.1 sends it out. No I have not talked to the engineers. It seems CBS stopped sending it in many markets and supposedly fixed a problem and is sending it out again. Just wondering if other PALDVR owners who lost TVGOS have it back.....except for me.

Am I now the only person in America without TVGOS being seen by their PALDVR? Neither one of my 2 boxes fed by 2 different antennas pick it up.

You did do a "factory reset" from the menu, didn't you! You will also have to wait probably several hours after you turn the pal off to get the TVGOS back.

It just doesn't work that way. Just because CBS turns off the TVGOS doesn't mean that the guide data would instantly vanish from the DTVPal. If CBS turned it off after she saw 7 days of listings yesterday, it would not go back to 3 days of listings, it would still show 7 days of listings. Now if she unplugged and replugged the DTVPal, then she would only see PSIP data for about 10 minutes, before the TV Guide data was displayed again. Could that be what she did when she saw partial listings?

Mark
I can only tell you what she tells me. After 3 days she got no information. For a few hours. She has checked everyday since Sat and the 7 day TVGOS is there. It keeps increasing by a day. So it is Back 100%

Am I now the only person in America without TVGOS being seen by their PALDVR? Neither one of my 2 boxes fed by 2 different antennas pick it up.

It seems this way. This is why I am leaning toward something with your equipment or antenna has moved ect.

Maybe Psmith can give you a list of things to try or change? He has the most knowledge here with Tech stuff (DTVpal)

CBS NYC 2.1 sends it out. No I have not talked to the engineers. It seems CBS stopped sending it in many markets and supposedly fixed a problem and is sending it out again. Just wondering if other PALDVR owners who lost TVGOS have it back.....except for me.

Well you know for a fact that We got it back. I hope others chime in

Very recently I've started having problems with some recordings. The picture will freeze during playback, but will let me use skip or fast forward (at any of 4x, 15x, 60x etc) - but when I try play again it will freeze. The last time it happened the problem cleared up about about 2 hours into a 3 hour recording i.e. it played back normally from the 2 hour mark. I've tried rebooting the machine and replaying the recording from the start but that doesn't fix it.

It has only happened with a few recordings so far - most are fine. I haven't noticed any pattern to it e.g. whether it happens for certain channels only, whether 2 recordings are happening at once etc.

I'm wondering if there could be a problem with a portion of the hard drive. Has anyone else experienced similar issues or have an opinion on the root cause of the problem?

If I need to replace the hard drive, does anyone know if the Western Digital WD10EURS model would be compatible? It's not listed in the FAQ as a recommended drive.

Thanks for any help...Mine used to do that. I figured that, maybe, there was a defective spot on the HD that was outputting data that hung up the processor. The next time that the problem occurred, I kept the recording and locked it to prevent accidental erasure and the problem has not reoccurred.

CBS NYC 2.1 sends it out. No I have not talked to the engineers. It seems CBS stopped sending it in many markets and supposedly fixed a problem and is sending it out again. Just wondering if other PALDVR owners who lost TVGOS have it back.....except for me.

Many markets? I only know of two areas that have been down NY, and Philadelphia. I don't know of any others where TVGOS was down.

I would do the Factory Default from the menu again. Do it tonight before midnight (making sure you enter your correct zip code), and then turn it off until morning. No listing data is sent out after 5:00pm, and the first listing data of the day is sent out at 1:00am. So if you reset after 5:00pm, there is no way you'll get the TV Guide logo before 1:30am.

Mark

Many markets? I only know of two areas that have been down NY, and Philadelphia. I don't know of any others where TVGOS was down.

I would do the Factory Default from the menu again. Do it tonight before midnight (making sure you enter your correct zip code), and then turn it off until morning. No listing data is sent out after 5:00pm, and the first listing data of the day is sent out at 1:00am. So if you reset after 5:00pm, there is no way you'll get the TV Guide logo before 1:30am.

Mark

OK! Still nothing here but I will try again and again....

A lot of people don't say where they are from so I may have assumed.....

If you are going to have her look again, there is an easier way to get to the end of the guide. When you bring up the guide, just enter the number of hours you want to go out, and then press the right arrow. The guide will jump to that spot. If I want to go to the end of the guide, I bring up the guide enter 200, and then right arrow, and I'm there (there is actually less than 200 hours of data, but 200 will always go to the end.
I've had my DVR since Dec. 2008 and I never knew that.
Thanks for posting this cool feature! :cool:

It's been a standard feature on Dish DVRs almost since they started making them

I received the following info from WCFE Plattsburgh 57 PBS

ROVI did not renew its contract with National Datacast, who was brokering the bits for us,and we were instructed to curtail the service and return their equipment which we did. Sorry for the loss of service but it is out of our hands.

So it is probably gone for good!

I received the following info from WCFE Plattsburgh 57 PBS

ROVI did not renew its contract with National Datacast, who was brokering the bits for us,and we were instructed to curtail the service and return their equipment which we did. Sorry for the loss of service but it is out of our hands.

So it is probably gone for good!
Maybe not. PBS was using National Datacast since it was spun off from PBS itself (http://www.nationaldatacast.com/pages/about.htm), so maybe some other non-PBS "datacast" service will provide or is providing the TVGOS info?

In my DMA there are two stations broadcasting TVGOS data,
the CBS station and the PBS station.

I had also received the folowing message from WCAX (CBS in Burlington) :

I checked with my engineering staff here and we are not receiving any information from ROVI.

Verdunn, how about ABC (WVNY) - rabbitears shows WCFE and WVNY as TVGOS stations, as of Sept. 2011. Maybe ABC is continuing with it alone.

http://www.rabbitears.info/market.php?request=tvgos

Hi, I'm stuck on the F201 firmware and have been having the reboot issues. I was wondering if someone could email me the F208 firmware since I can't find it anywhere. Thanks!

@TalkingRat

I do not receive that ABC station. Signal is not strong enough and it is a VHF station (13).

Thanks to you and to others who tried to help.

CBS NYC 2.1 sends it out. No I have not talked to the engineers. It seems CBS stopped sending it in many markets and supposedly fixed a problem and is sending it out again. Just wondering if other PALDVR owners who lost TVGOS have it back.....except for me.

I also have a PAL DVR with the same issue. I have tried the unplug and wait and factory resetting the unit. No joy. Funny thing is that both of my Sony DHG-HDD500's did start receiving listings over a week ago.

I also have a PAL DVR with the same issue. I have tried the unplug and wait and factory resetting the unit. No joy. Funny thing is that both of my Sony DHG-HDD500's did start receiving listings over a week ago.

You know I just thought of something that might help. Worth a try. remember people talking about freezing issue or loop issues?

Why don't you guys try this

1) Disconnect antenna from DTVpal. (Leave Connection from Pal to TV)

2) Do a factory reset

3) reconnect antenna and do another factory reset.

4) Pray :D


It can not hurt. that process fixed other pal problems. Might work for this?

I also have a PAL DVR with the same issue. I have tried the unplug and wait and factory resetting the unit. No joy. Funny thing is that both of my Sony DHG-HDD500's did start receiving listings over a week ago.

This is strange indeed. I am still missing TVGOS and have run out of ideas short of unplugging for a week.

This goes back more than a year but I did notice that when I got my second one it picked up TVGOS right away. My first one had problems but when I put a new HD in it it picked up TVGOS right away. So I am wondering if it may be HD related. That maybe reformatting the HD might wipe some settings for TVGOS that have been stored that are no longer valid?

You know I just thought of something that might help. Worth a try. remember people talking about freezing issue or loop issues?

Why don't you guys try this

1) Disconnect antenna from DTVpal. (Leave Connection from Pal to TV)

2) Do a factory reset

3) reconnect antenna and do another factory reset.

4) Pray :D


It can not hurt. that process fixed other pal problems. Might work for this?

Question: when TVGOS went away did your mom still use the PALDVR? DId she unplugg it at all? Do you have separate antenna feeds to the TV and PALDVR? Wondering if she stopped recording and only watched TV with the feed from the antenna and unplugged the PALDVR.

Question: when TVGOS went away did your mom still use the PALDVR? DId she unplugg it at all? Do you have separate antenna feeds to the TV and PALDVR? Wondering if she stopped recording and only watched TV with the feed from the antenna and unplugged the PALDVR.

No DTVpal always on and when she lost TVGOS she got PSIP (hated it) then got TVGOS back. She would not know how to disconnect the box ect.
No separate feed to tv. HD Coax from Antenna to DTVpal, Then HD coax from DTVpal to TV.

A current link for the F208 Firmware has been added to the very top of the first post.

Thanks to AVS member P Smith for the suggestion and link.

A current link for the F208 Firmware has been added to the very top of the first post.

Thanks to AVS member P Smith for the suggestion and link.Finally. ;)

How does the tuner do with weak signal levels say 65 or lower? Where I live we have several low power, semi-locals and a couple fringe signals. I have the DTVPAL Plus converter with the new enhanced digital tuner which will hold and lock a signal 90miles away, signal level most of the time is around 60 with very little drop out. How does DTVPal DVR compare?

How does the tuner do with weak signal levels say 65 or lower? Where I live we have several low power, semi-locals and a couple fringe signals. I have the DTVPAL Plus converter with the new enhanced digital tuner which will hold and lock a signal 90miles away, signal level most of the time is around 60 with very little drop out. How does DTVPal DVR compare?

Speaking for my situation (location, 2 antennas and 2 PALDVRS) I find that VHF signals of 60 and above and UHF of 70 and above are held and locked for the most part. Better yet are VHF of 70 and above and UHF of 80 and above.

Greetings,
Thanks to this Forum, I figured out that my local WUSA CBS station was the one that was responsible for sending out the TVGOS time stamp. Its lack of accuracy has been driving me crazy. So I sent the following email. And below it, is the reply from the Director of Technology & Operations at WUSA, in D.C. There does not seem to be any way to manually change the local time in the DTVPal to be accurate. I have tried unplug/re-plug. But nothing helps. Is there any way to do this and not be dependent on WUSA working out this problem?
Gary
------------------------------
Question to WUSA:
Greetings,
I receive my TV signal over-the-air. I understand that the TVGOS local time stamp is sent out by WUSA. However, the local time is constantly inaccurate. Today, as an example, the TVGOS time is about 5 minutes earlier than the correct time. Sometimes it is even 9 or 10 minutes too early. This causes my DVR to start recording the scheduled show 5 - 10 late, therefore missing the recording of the first part of each scheduled show.

Can you tell me why this is happening or what I can do about this. My DVR's (DTVPal) local time can not be set manually. It can only be set through the TVGOS signal. I'd appreciate any help you can give me.
--------------------
Reply from WUSA:
TVGOS is currently working on how to resolve this problem. There is not a whole lot I can do as I merely provide rack space for their server. I can tell you we are having daily conversations regarding this issue. I don’t like it when folks have a problem with my station. I like to get them corrected asap. Sorry I don’t have better news.

How does the tuner do with weak signal levels say 65 or lower? Where I live we have several low power, semi-locals and a couple fringe signals. I have the DTVPAL Plus converter with the new enhanced digital tuner which will hold and lock a signal 90miles away, signal level most of the time is around 60 with very little drop out. How does DTVPal DVR compare?

IIRC, both boxes use the same Microtune tuner, so I would think you'd be fine if you're happy with the Plus. The tuner is reportedly better for separating out co-channel interference. In my case, apparent signal weakness is multipath, and the Pal is my weakest tuner for holding on in those conditions.

Greetings,
Thanks to this Forum, I figured out that my local WUSA CBS station was the one that was responsible for sending out the TVGOS time stamp. Its lack of accuracy has been driving me crazy. So I sent the following email. And below it, is the reply from the Director of Technology & Operations at WUSA, in D.C. There does not seem to be any way to manually change the local time in the DTVPal to be accurate. I have tried unplug/re-plug. But nothing helps. Is there any way to do this and not be dependent on WUSA working out this problem?
Gary
[...]


The only way I know of to get manual control of the time back, is to do a Factory Default from the menu (this is not the same thing as holding the power button for 10 seconds, or unplugging and replugging the DTVPal). After doing the Factory Default, do not set a zip code (leave it at 00000). You will now have full manual control for setting the clock, however you will no longer receive TVGOS data, and you will only see the PSIP guide on your DTVPal.

About a month ago I suggested this fix to someone here, and they claimed that this didn't work for them, but they also said that after the factory default they changed the zip code to 00000. If you do a real factory default it will already be 00000, and you don't need to change it. This lead me to believe that he didn't do the Factory Default, but only did the "hold the power button for 10 seconds" reset. I have since verified that this does in fact work.

Mark

Greetings,
I gave it a try. It appears that it worked. I did the Factory Default and left the zip code at 00000. The time, when I went to the Guide, was back to being correct and I can, if I need to, manually set the time, now.

However, you said that I will no longer receive the TVGOS data, but I checked, and the TVGOS is all there as before, for the 7 days. So can you explain what the 'PSIP guide' is vs. the 'TVGOS.' I don't see a difference in what I now have. Thanks for the tip and I'll keep you posted if things change.
Thanks... Gary
===============================
The only way I know of to get manual control of the time back, is to do a Factory Default from the menu (this is not the same thing as holding the power button for 10 seconds, or unplugging and replugging the DTVPal). After doing the Factory Default, do not set a zip code (leave it at 00000). You will now have full manual control for setting the clock, however you will no longer receive TVGOS data, and you will only see the PSIP guide on your DTVPal.

About a month ago I suggested this fix to someone here, and they claimed that this didn't work for them, but they also said that after the factory default they changed the zip code to 00000. If you do a real factory default it will already be 00000, and you don't need to change it. This lead me to believe that he didn't do the Factory Default, but only did the "hold the power button for 10 seconds" reset. I have since verified that this does in fact work.
Mark

Greetings,
This is a quick followup to my previous posting.

As I mentioned, the TVGOS guide was there after I did the Factory Default. However, I see now that most of the sections have 'information unavailable'. But maybe they would have been populated as time goes by. However, I then changed my zip code from 00000 to 20190. Before I had it as 20194, which is more accurate, but I made this slight change just to see what would happen. I made the change to 20190 and expected to not be able to set the time manually, as before. However, now I am still able to set the local time manually...I am not locked out as before. So I am really wondering what is going on. I am hoping that, over the next few hours or days, the TVGOS will populate as before and I will be able to set/re-set the local time if it goes off track again. Any explanations for this???
Gary

There can be a delay of several hours to even a day or two before TVGOS locks the clock.

A current link for the F208 Firmware has been added to the very top of the first post.

Thanks to AVS member P Smith for the suggestion and link.

The link for the new firmware brings me to zippyshare.com and has a weird file name for the file. When I download it and put it in a update folder. I plug in the usb stick. The dvr see's the usb drive but nothing happens. Can you check the file please? Or can someone please email me the firmware for F208?

Emdev2@aol.com

Thanks

Make sure you did not enter anything under "Alternate Zip Codes." is something that I see in the first post with all the info on the PALDVR for making sure you get TVGOS. I'm scratching my head on this one as I never have found anything in the menu that says Alternate ZIP codes. I have only found one spot where it asks for a ZIP code. Are there 2 areas in the menu that ask for zip codes?

Can anyone shed some light on this?

Make sure you did not enter anything under "Alternate Zip Codes." is something that I see in the first post with all the info on the PALDVR for making sure you get TVGOS. I'm scratching my head on this one as I never have found anything in the menu that says Alternate ZIP codes. I have only found one spot where it asks for a ZIP code. Are there 2 areas in the menu that ask for zip codes?

Can anyone shed some light on this?
Alternate Zip codes is ONLY for feeding TVGOS data to an analog device.
It disables most features in the Pal DVR.

There can be a delay of several hours to even a day or two before TVGOS locks the clock.
======================
Chuck44,
Yes, I understand. And I just noticed that the ability to change the local time is now locked-out and the local time is now creeping to be more incorrect--its already 2 minutes off.

So I repeated the Factory Default and kept the zip code at 00000. I will leave it alone for a while to see how the guide gets populated. I also notice that the little TVGOS icon is not shown in the program guide anymore. So it must be that the 'PSIP Guide' is populating the program guide. But I still don't know what the difference is between the PSID and the TVGOS results will be. Can you explain what the difference will be? I am going to let the program guide (whatever I have at this point) to populate.
Gary

You may have to 'visit' each station of interest to get its PSIP guide info.

Donald1800

Alternate Zip codes is ONLY for feeding TVGOS data to an analog device.
It disables most features in the Pal DVR.

OK but where in the world is it in setup? I don't think I ever saw this in going into the menu of options. I have only found one place for zip code and it did not say alternate zip code. I just want to make sure I don't have alternate zip code valued.

Can you explain what the difference will be? I am going to let the program guide (whatever I have at this point) to populate.
Gary
TVGOS usually has 7 or 8 days of program info. PSIP only has a few hours.
TVGOS (TV Guide Onscreen) is supplied by a national network, while PSIP info is supplied by each local station.

OK but where in the world is it in setup? I don't think I ever saw this in going into the menu of options. I have only found one place for zip code and it did not say alternate zip code. I just want to make sure I don't have alternate zip code valued.
Setup, System Setup, TV Guide and Guide +

to : Emdev2
Rename that file you downloaded to : TR50_F208_0HUC00.upd

How does the tuner do with weak signal levels say 65 or lower? Where I live we have several low power, semi-locals and a couple fringe signals. I have the DTVPAL Plus converter with the new enhanced digital tuner which will hold and lock a signal 90miles away, signal level most of the time is around 60 with very little drop out. How does DTVPal DVR compare?

It goes beyond signal strength to signal quality etc. I have a DB-8 with a high gain amplifier. With the amplifier unplugged I get a higher signal strength indication on local channels than when I plug in the power supply. I assume this is because the added signal drives the AGC down or the pre-amp is noisy.

Below an indicated strength of about 60 or so I have problems with severe dropouts.

The only way I know of to get manual control of the time back, is to do a Factory Default from the menu (this is not the same thing as holding the power button for 10 seconds, or unplugging and replugging the DTVPal). After doing the Factory Default, do not set a zip code (leave it at 00000). You will now have full manual control for setting the clock, however you will no longer receive TVGOS data, and you will only see the PSIP guide on your DTVPal.

About a month ago I suggested this fix to someone here, and they claimed that this didn't work for them, but they also said that after the factory default they changed the zip code to 00000. If you do a real factory default it will already be 00000, and you don't need to change it. This lead me to believe that he didn't do the Factory Default, but only did the "hold the power button for 10 seconds" reset. I have since verified that this does in fact work.

Mark
Sometimes just doing the soft reset (10 sec button) works for me. It keeps the TVGOS guide data but uses PSIP time <u>until</u> the box reacquires TVGOS so it is good for an evening if I am lucky.

This is strange indeed. I am still missing TVGOS and have run out of ideas short of unplugging for a week.

This goes back more than a year but I did notice that when I got my second one it picked up TVGOS right away. My first one had problems but when I put a new HD in it it picked up TVGOS right away. So I am wondering if it may be HD related. That maybe reformatting the HD might wipe some settings for TVGOS that have been stored that are no longer valid?

LenL,

I have 2 different types of DTVPal devices, in different usage modes, neither of which has resumed population of TVGOS data since CBS recently "resumed" transmitting it. One is the DTVPal DVR, which I admit I have not yet tried the Factory Reset method to spark repopulation. The reason I have not yet tried on the DVR is because the other device is a DTVPal+ set to TVGOS mode & connected to an LG LST-3410A DVR to populate its TVGOS data, and since I repowered the DTVPal+ last week after reading that transmission was resumed, I have been unable to receive any TVGOS data from this unit.

With the 3410A, there are maintenance commands which take you to screens where all sorts of TVGOS data statistics are displayed. When TVGOS data is being received, the data numbers can be seen updating in real time. So far, nada. The Host station ID & Channel refuse to be identified. I am very familiar with all the hoops that can be used to jump start this process & none of them are currently amounting to success. Prior to the start of the CBS TVGOS outage in late November, I never had any difficulty kickstarting this process even though it might fail for a day or two on occasion (usually Sundays into Mondays.) If I lost the Host ID & Channel for some reason, it was usually reacquired within a few hours of a "reset".

Because this process was so reliable prior to last November, I have my doubts about current transmission when I can't see any data packet updates on the DTVPal+ feed to the LG.

I'm right across the river from NYC & have a good rooftop antenna with a strong CBS signal, so that's not an issue.

Sometimes just doing the soft reset (10 sec button) works for me. It keeps the TVGOS guide data but uses PSIP time <u>until</u> the box reacquires TVGOS so it is good for an evening if I am lucky.

It has been mentioned here several times that in areas where the TVGOS clock loses time, that it catches back up in the evening (I seem to remember it takes about 10 minutes after the last TVGOS download ends at 6:15pm for it to get caught back up). After a soft reset, your DVR is not reverting to PSIP but is still getting the (now corrected) time from TVGOS. This reset forces the DVR to resync with the TVGOS time. If you go in and try to set the clock manually during this time, it will still be grayed out, and indicate that it was set by TVGOS.

Mark

Setup, System Setup, TV Guide and Guide +

Well this makes sense then .....as this is where you use your other devices to receive TVGOS. I think the info on page one of this thread needs to be reworded as it is misleading or confusing.

LenL,

I have 2 different types of DTVPal devices, in different usage modes, neither of which has resumed population of TVGOS data since CBS recently "resumed" transmitting it. One is the DTVPal DVR, which I admit I have not yet tried the Factory Reset method to spark repopulation. The reason I have not yet tried on the DVR is because the other device is a DTVPal+ set to TVGOS mode & connected to an LG LST-3410A DVR to populate its TVGOS data, and since I repowered the DTVPal+ last week after reading that transmission was resumed, I have been unable to receive any TVGOS data from this unit.

With the 3410A, there are maintenance commands which take you to screens where all sorts of TVGOS data statistics are displayed. When TVGOS data is being received, the data numbers can be seen updating in real time. So far, nada. The Host station ID & Channel refuse to be identified. I am very familiar with all the hoops that can be used to jump start this process & none of them are currently amounting to success. Prior to the start of the CBS TVGOS outage in late November, I never had any difficulty kickstarting this process even though it might fail for a day or two on occasion (usually Sundays into Mondays.) If I lost the Host ID & Channel for some reason, it was usually reacquired within a few hours of a "reset".

Because this process was so reliable prior to last November, I have my doubts about current transmission when I can't see any data packet updates on the DTVPal+ feed to the LG.

I'm right across the river from NYC & have a good rooftop antenna with a strong CBS signal, so that's not an issue.

I feel better knowing there are others in the same situation as I am in! Still according to others (at least Keyboard21) they are receiving TVGOS with their PALDVR. So I wonder if they are getting it from CBS or they are in an area where they can get it from another source like PBS.

Very strange!

TVGOS usually has 7 or 8 days of program info. PSIP only has a few hours.
TVGOS (TV Guide Onscreen) is supplied by a national network, while PSIP info is supplied by each local station.
=============================
Chuck44,
Yes, I am getting the hang of it. I am now getting the PSIP guide info. Since I changed from TVGOS to PSIP, the times have been right on target. I see that, depending on the station, the programs will populate for up to 7 or 10 hours ahead. It really is a shame we have to choose between correct times and the full TV Guide programming info. I will stick with the PSIP to see how it goes for now. I just can't set the DVR for programs too far into the evening unless I use my paper TV Guide to check the times they are on. But if there is 'no available information', its blocks of time are set for an hour so I am not sure yet what will happen if I want only one of the half-hour programs...will it record both or just one or which one? I'll find out tonight.
How difficult can it be for TVGOS to get its time function to work?????? :confused:
Gary

How difficult can it be for TVGOS to get its time function to work?????? :confused:
Gary
It might be helpful to know where you are located.
In my area TVGOS has the correct time.

It might be helpful to know where you are located.
In my area TVGOS has the correct time.
============================
Chuck44,
I am in the Washington, DC metro area. Check out my #13813 posting. The local CBS WUSA puts out the TVGOS info but the station's Director of Technology & Operations seems to be well aware of the problem and is frustrated, too, that the TVGOS guys (whoever they are and wherever they are) just don't have there stuff together, apparently. My TVGOS time will start out correct but immediately starts to drift to the point that recordings starting 10 minutes after the shows have started.....:confused: :confused: :confused:
So far the PSIP clock time has been accurate and does not drift. I wish I know who/where the TVGOS gods are so I can send them an email!
Gary

I wish I know who/where the TVGOS gods are so I can send them an email!
The company is Rovi, and somewhere back in this thread is their contact info,
but AFAIK nobody has ever gotten any satisfaction from them (they always blame someone else, such as our DVRs).

The company is Rovi, and somewhere back in this thread is their contact info,
but AFAIK nobody has ever gotten any satisfaction from them (they always blame someone else, such as our DVRs).
=======================
Chuck44,
You made a bell ring in my head when you mentioned "Rovi". I remembered that I had sent an email to them back in May 2011 about the same problem. They seemed to be concerned back then, and I think the time might have been corrected...or it might have just been a coincidence. Here is the email address I used:
ROVI CE Support <ce_customer_support@rovicorp.com>

I found this as a site for 'support'.
http://www.rovicorp.com/support/8459.htm

I just sent them another email about the time drifting. We'll see what happens.
Thanks... Gary

=======================
Chuck44,
You made a bell ring in my head when you mentioned "Rovi". I remembered that I had sent an email to them back in May 2011 about the same problem. They seemed to be concerned back then, and I think the time might have been corrected...or it might have just been a coincidence. Here is the email address I used:
ROVI CE Support <ce_customer_support@rovicorp.com>

I found this as a site for 'support'.
http://www.rovicorp.com/support/8459.htm

I just sent them another email about the time drifting. We'll see what happens.
Thanks... Gary
Good luck.

Good luck.
====================
Chuck44,
Ha... no luck!
After replying to the old email from them, the email was bounced back with:
An email was received for a very old closed case. Due to the age of this case, no further action will be taken on this case. In order to receive support for an existing or new case, please contact Rovi Support at www.rovicorp.com.


I sent two more emails after changing the Subject to remove any indication of an old case number. Same thing. So I called their 800-386-7380 tech support number and waited for a real person, which never happened, and I left my name/number at the end of their recording.
Gary

=============================
Chuck44,
Yes, I am getting the hang of it. I am now getting the PSIP guide info. Since I changed from TVGOS to PSIP, the times have been right on target. I see that, depending on the station, the programs will populate for up to 7 or 10 hours ahead. It really is a shame we have to choose between correct times and the full TV Guide programming info. I will stick with the PSIP to see how it goes for now. I just can't set the DVR for programs too far into the evening unless I use my paper TV Guide to check the times they are on. But if there is 'no available information', its blocks of time are set for an hour so I am not sure yet what will happen if I want only one of the half-hour programs...will it record both or just one or which one? I'll find out tonight.
How difficult can it be for TVGOS to get its time function to work?????? :confused:
Gary
Keep an eye on the clock. In my area, SW Florida, time is set by PSIP and can be as much as 5 minutes slow to 5 minutes fast.

====================
Chuck44,
Ha... no luck!
After replying to the old email from them, the email was bounced back with:
An email was received for a very old closed case. Due to the age of this case, no further action will be taken on this case. In order to receive support for an existing or new case, please contact Rovi Support at www.rovicorp.com.


I sent two more emails after changing the Subject to remove any indication of an old case number. Same thing. So I called their 800-386-7380 tech support number and waited for a real person, which never happened, and I left my name/number at the end of their recording.
Gary

I could stop by at the company building with a stack of your requests printed on paper and ask to accept them some legal way. Not sure - you would give me some ideas for that.
Perhaps hard copy could do that push ?

Actually certified mail should be used, but I'm willing to cut your expenses, guys. :)

FYI, the ROVI time in SoCal seems to be fairly accurate today, within a second or two.

I feel better knowing there are others in the same situation as I am in! Still according to others (at least Keyboard21) they are receiving TVGOS with their PALDVR. So I wonder if they are getting it from CBS or they are in an area where they can get it from another source like PBS.

Very strange!

From what people have been saying on the Sony forum, TVGOS has been out for several days now in NY. Apparently it was only turned on for a couple of days, but seems to have been shut off again ever since. This would explain why you can't get the listings. I would have mentioned this sooner, but the first guy who reported having problems with listings is on cable, and someone else who is OTA said at the same time that he had partial listings. Apparently now though they are both without, and have been for several days. I think it has been almost a week since keyboard21's aunt claimed to have full listings, so I suspect that her listings are probably gone by now also.

Mark

============================
Chuck44,
I am in the Washington, DC metro area. Check out my #13813 posting. The local CBS WUSA puts out the TVGOS info but the station's Director of Technology & Operations seems to be well aware of the problem and is frustrated, too, that the TVGOS guys (whoever they are and wherever they are) just don't have there stuff together, apparently. My TVGOS time will start out correct but immediately starts to drift to the point that recordings starting 10 minutes after the shows have started.....:confused: :confused: :confused:
So far the PSIP clock time has been accurate and does not drift. I wish I know who/where the TVGOS gods are so I can send them an email!
Gary

If you can't live without TVGOS, then here is something to try. First go in and set your correct zip code, so TVGOS will take over. Now here (http://www.avsforum.com/avs-vb/showthread.php?p=21019178#post21019178) is a link to my analysis of a log file posted by Nitewatchman. The log is from WHIO in Ohio, but I believe that Washington DC has this same problem. Here is how I would attempt to fix it.

Turn on the DTVPal, and bring up the menu. Once in the menu, select Setup (3), and then Updates (7).

Select 'Enable', and enter a time of 5:30pm. Turn off the DVR.

Tomorrow, about 5:20pm, turn on the DVR, and see how far off the clock is, then turn it back off.

At about 5:45pm (15 minutes after the update "reboot"), turn the DVR on, and see how far off the clock is. If the clock is correct, this may be the fix. However, you should turn off the DVR again, and wait until about 6:30pm to check the clock again. If the clock is correct at 6:30pm, then it should stay correct the rest of the evening. Now if you leave the updates on, and set to 5:30pm, it should always be correct during the evening. If this worked, but you sometimes are recording at 5:30pm, then try setting the update time to 3:10pm instead.

If the clock is off at 6:30pm, report how far off it is. We may need to tweek this a little bit to get closer to the point that the time is correct.

Mark

This is the text of a message I received Thursday from ROVI regarding my issues receiving TVGOS in the NYC area:

Data was back for a few days, but does appear to be down again. Engineers are
investigating, and we are hopeful that the issue will be resolved soon. This ticket is
being moved to our escalation queue, and once an update is received here we will contact
you. Your patience is appreciated.

CE Technical Support
Rovi

Hello-

My CM7000PAL has been showing an error message -- "Error A652, Software Update Error, IP Connection Lost....". This happens only occasionally, it doesn't cause obvious harm (click on OK and it disappears), but it is still irritating. In looking up the error message, it seems the DVR is attempting to do a software update, but without an active IP connection.

After the recent problems with clock accuracy in the Wash DC metro area (Ch 9 WUSA, etc.), I have my CM7000PAL set to do automatic daily firmware updates. If possible, I would rather leave it that way. Other than this update setting, is there some workaround to kill the error message? Thanks in advance for any help......!

John

Only adding active Ethernet cable will eliminate the message.

Hello-

My CM7000PAL has been showing an error message -- "Error A652, Software Update Error, IP Connection Lost....". This happens only occasionally, it doesn't cause obvious harm (click on OK and it disappears), but it is still irritating. In looking up the error message, it seems the DVR is attempting to do a software update, but without an active IP connection.

After the recent problems with clock accuracy in the Wash DC metro area (Ch 9 WUSA, etc.), I have my CM7000PAL set to do automatic daily firmware updates. If possible, I would rather leave it that way. Other than this update setting, is there some workaround to kill the error message? Thanks in advance for any help......!

John

I don't know of a way to get rid of that message, since you are telling the DVR to check for updates daily, but it doesn't have a connection to the internet. This would also be a downside to my suggestion above. I'm curious what time you have yours set to check for updates, and does the clock stay correct?

Mark

I don't know of a way to get rid of that message, since you are telling the DVR to check for updates daily, but it doesn't have a connection to the internet. This would also be a downside to my suggestion above. I'm curious what time you have yours set to check for updates, and does the clock stay correct?

Mark

Most people just turn off updates since we don't expect to receive one.

Most people just turn off updates since we don't expect to receive one.

Yes, my updates are disabled. For people with the clock issues, who are using the updates reboot feature to force the clock to set at times when the TVGOS clock is correct, it would be an issue.

Mark

Get the DVR connected to Internet would possibly eliminate the message (and could produce another one, if exist, - "can't connect to the dish web site").

2 questions

1) What is the exact directions to turn off internet updates? Stupid me. I did a facotry reset for my aunt today and forgot to turn off the internet updates. I just go to the menu and find it. She needs step by step directions Could someone help me?

2) Also we lost TVGOS ,but the Tvguide Icon stayed on the guide? Why is that? It did go off after factory reset

...2) Also we lost TVGOS ,but the Tvguide Icon stayed on the guide? Why is that?Do you still have TVGOS data before it went out?

Do you still have TVGOS data before it went out?

No I checked we had Tvguide logo but NO 7 day info. Wierd

Could you do me a favor and give me step by step directions to turn off internet updates. I need to talk my aunt through it

No I checked we had Tvguide logo but NO 7 day info. Wierd

Could you do me a favor and give me step by step directions to turn off internet updates. I need to talk my aunt through itI think it was in its settings. I don't remember. I am not at my DVR to check and it will be several hours. :( Maybe someone else will answer your question.

2 questions

1) What is the exact directions to turn off internet updates? Stupid me. I did a facotry reset for my aunt today and forgot to turn off the internet updates. I just go to the menu and find it. She needs step by step directions Could someone help me?
Setup, Updates, Disabled, Done.

2) Also we lost TVGOS ,but the Tvguide Icon stayed on the guide? Why is that? It did go off after factory reset.
If you had TVGOS info before, it should come back in time. Give it a few hours.

Setup, Updates, Disabled, Done.


If you had TVGOS info before, it should come back in time. Give it a few hours.

Seems that CBS NY is down again with TVGOS. Someone e-mailed Rovi last night.

CBS is been having lots of TVGOS trouble:mad:

Thank You for info

[...]
2) Also we lost TVGOS ,but the Tvguide Icon stayed on the guide? Why is that? It did go off after factory reset

I don't think that TV Guide Logo ever turns off on its own. It simply indicates that at some point it was receiving TVGOS data. Don't rely on the presence of that logo as an indication that it is currently receiving TVGOS data.

Mark

I don't think that TV Guide Logo ever turns off on its own. It simply indicates that at some point it was receiving TVGOS data. Don't rely on the presence of that logo as an indication that it is currently receiving TVGOS data.

MarkThe logo turns off 8 days after TVGOS data is lost. It won't return spontaneously when TVGOS data resumes... that requires some manual intervention such as re-booting or possibly even a reset to factory defaults.

The logo turns off 8 days after TVGOS data is lost. It won't return spontaneously when TVGOS data resumes... that requires some manual intervention such as re-booting or possibly even a reset to factory defaults.

So basically when the guide is completely empty of TVGOS data, it will turn off. I just remembered people mentioning when they discovered the guide was missing several days, that the logo was still there.

Mark

Seems that CBS NY is down again with TVGOS. Someone e-mailed Rovi last night.

CBS is been having lots of TVGOS trouble:mad:

Thank You for info

What is puzzling is that it appears that CBS is OK with sending TVGOS in many parts of the country but in the NYC area and I guess a few others they are having an issue. Maybe we should suggest they talk to the engineers at CBS in other parts of the country?

What is puzzling is that it appears that CBS is OK with sending TVGOS in many parts of the country but in the NYC area and I guess a few others they are having an issue. Maybe we should suggest they talk to the engineers at CBS in other parts of the country?

They also sent the data out for more than 3 years in NYC before having an issue.

Mark

Only adding active Ethernet cable will eliminate the message.

I did exactly that a few weeks ago after getting the internet piped to my home theater setup. It was only for a few minutes, but I wanted to see if a firmware update might be available (oh sure), no such luck, so I then disconnected the internet feed. Now that I think about it, this error A652 message may have in fact begun to appear as a direct result of this temporary connection. Hmm....

I don't know of a way to get rid of that message, since you are telling the DVR to check for updates daily, but it doesn't have a connection to the internet. This would also be a downside to my suggestion above. I'm curious what time you have yours set to check for updates, and does the clock stay correct?

Mark

After the debacle with clock inaccuracy last year (Wash DC area), I've been watching the clock and fiddling with the auto update feature, not every day, but every so often. The minute that I think the problem has permanently been rectified and that I can turn off the updates, I learn that this may not be so. That said, and given that enabling updates often helps and never hurts anything (or at least that's the way it used to be), I keep doing updates.

Most people just turn off updates since we don't expect to receive one.

Oh I don't expect to see a true update either. I keep the updates enabled to force the clock to remain accurate (Wash DC area problem) . Bear in mind that the auto updates have been used here for a long time, and the error a652 message just recently began to appear. The only change of late was that I momentarily tested an internet feed to the DVR and then immediately disconnected it. The more I think about it, the more I wonder if the box now expects the internet to be available even though it isn't. If so, I wish I had never tried that internet test.

Yes, my updates are disabled. For people with the clock issues, who are using the updates reboot feature to force the clock to set at times when the TVGOS clock is correct, it would be an issue.

Mark

Yup, that's my situation. And this never used to cause a problem -- the A652 message is new. As said in other replies here, I suspect the problem may have come about as a result of a recent quick test of the DVR's internet connectivity feature.

Get the DVR connected to Internet would possibly eliminate the message (and could produce another one, if exist, - "can't connect to the dish web site").

Reconnecting the DVR to the internet might eliminate the error A652 message? I'm almost afraid to try lest the problem worsen <g>! So do what, just reconnect the cable for a day or two?

Yes, then watch for a couple days and report back to us.

The "UPDATE" issue has been discussed many time and has been suggested to be "disabled" since the PAL came out. Very good reading in post #1

After the debacle with clock inaccuracy last year (Wash DC area), I've been watching the clock and fiddling with the auto update feature, not every day, but every so often. The minute that I think the problem has permanently been rectified and that I can turn off the updates, I learn that this may not be so. That said, and given that enabling updates often helps and never hurts anything (or at least that's the way it used to be), I keep doing updates.

That is great that it works for you, but what time do you have it set for?

Mark

That is great that it works for you, but what time do you have it set for?

Mark

Reading through these posts, I can't tell if many people are still having problems with clock time in DC or not? "The clock debacle last year" implies that it has been fixed, but it seems plenty of people are still doing the auto reboot jury rig to keep the clock set right?

My Sony DVR (OTA in DC, WUSA host) is normally off by 5-10 minutes, rendering it useless for shows that record back to back. DTVPal people in DC have accurate clocks these days, or no?

Reading through these posts, I can't tell if many people are still having problems with clock time in DC or not? "The clock debacle last year" implies that it has been fixed, but it seems plenty of people are still doing the auto reboot jury rig to keep the clock set right?

My Sony DVR (OTA in DC, WUSA host) is normally off by 5-10 minutes, rendering it useless for shows that record back to back. DTVPal people in DC have accurate clocks these days, or no?

I think a lot of people did the easiest thing, and switched their zip code to a Baltimore zip code. The Baltimore station doesn't have the clock problems, and is close enough that a lot of people receive it. From what I remember the problem never was fixed with WUSA.

Mark

The "UPDATE" issue has been discussed many time and has been suggested to be "disabled" since the PAL came out. Very good reading in post #1

I've read post #1 many times, and as you say, it's a good read and the place to start. However unfortunately the on-again, off-again clock problems in the Wash DC area frequently demand that updates be enabled. And on that topic, the clock setting inaccuracy problem here seems to be non existent for long lengths of time (or at least far better than it was at the peak of the problem last year). But then it seems to reappear, usually just after I've tried disabling updates. Murphy.

That is great that it works for you, but what time do you have it set for?

Mark

Currently I have the update time set to 6:55 PM. This came from the discussion and recommendations on this subject last year, but I have not personally proven that this time is optimum.

Reading through these posts, I can't tell if many people are still having problems with clock time in DC or not? "The clock debacle last year" implies that it has been fixed, but it seems plenty of people are still doing the auto reboot jury rig to keep the clock set right?

My Sony DVR (OTA in DC, WUSA host) is normally off by 5-10 minutes, rendering it useless for shows that record back to back. DTVPal people in DC have accurate clocks these days, or no?

I ~think~ the problem is better than it was, possibly fixed, but frankly we don't watch it that closely. Usually we no longer even think about it unless a recorded show appears to start early or late.

The irritating thing is that I/we never seemed to sort out exactly what was truly going on last year. Fingers were pointed at WUSA Ch 9, CBS in general, at Rovi, at TVGOS, etc. I even had a number of emails with the chief tech guy at WUSA who said little more than "they were very aware of the problem". However I never sorted out what had been the actual problem, who was at fault, nor how it was fixed (IF in fact it actually was). Technically speaking, all of this was anything by satisfying.

I think a lot of people did the easiest thing, and switched their zip code to a Baltimore zip code. The Baltimore station doesn't have the clock problems, and is close enough that a lot of people receive it. From what I remember the problem never was fixed with WUSA.

Mark

Right, that workaround was tried by many last year. For many of was a great fix, but it depended on the signal strength of the Baltimore CBS affiliate. I also seem to recall that many experienced listing problems with their TV Guide display after shifting their zip code (this seems to make sense if a person lives in one market yet gets updates for another).

Listening to you guys here for last years... , I'm wondering why it's happening at global (your states) scale ?

Is ROVI too greedy for the service and asking a lot of money from stations ?
Or opposite ? The fee is too small and ROVI can mishandle own boxes/data without penalties ?

We never had such issue in Bay Area.

Listening to you guys here foe last years... , I'm wondering why it's happening at global (your states) scale ?

Is ROVI too greedy for the service and asking a lot of money from stations ?
Or opposite ? The fee is too small and ROVI can mishandle own boxes/data without penalties ?

We never had such issue in Bay Area.

----"MONEY"----

Might be the key word here. In my opinion, it is inconceivable that the OTA corporate marketing model and DVR usage could coexist peacefully. I don't bypass all commercial, but I do on occasion (in a hurry or already seen that boring oratory) do my fair share. I figure 'large money markets' will be the first to draw a sword to the freedom OTA viewers have to skip commercials. Lets face it, regrettably, it only makes sense. The economy has hit the skids and 'Wall Street' is going to find a way to make a dollar.
Which probably, if one was a bug on the wall, the real reason Dish 'dished' the FREE OTA Guide DVR Project to begin with.

Just an opinion....no knowledge here. :(

----"MONEY"----

Might be the key word here. In my opinion, it is inconceivable that the OTA corporate marketing model and DVR usage could coexist peacefully. I don't bypass all commercial, but I do on occasion (in a hurry or already seen that boring oratory) do my fair share. I figure 'large money markets' will be the first to draw a sword to the freedom OTA viewers have to skip commercials. Lets face it, regrettably, it only makes sense. The economy has hit the skids and 'Wall Street' is going to find a way to make a dollar.
Which probably, if one was a bug on the wall, the real reason Dish 'dished' the FREE OTA Guide DVR Project to begin with.

Just an opinion....no knowledge here. :(
True, but bear in mind:

1) The only true "freeloaders" using the TVGOS OTA data are owners of the DTVPal and Sony DVRs. Combined they represent such a tiny percentage (actually better expressed in ppm!) of the viewing audience that I strongly doubt the number-crunchers are even aware of them, much less considering them when determining business models.

2) A much larger (but still fairly small) group of OTA viewers make use of the TVGOS data on "approved devices" (mostly TVs). These people are subjected to ads on their guide displays and hence are not "freeloaders", but rather are paying their own way. Also these people are not using DVRs so they don't have the ability to skip through commercials and hence are not a threat to the ad revenue in anyone's business model. Readers of this thread are like the fleas that ride on the birds that ride around on the backs of elephants. No other creatures on the Serengeti give them much thought...

I agree it would be interesting to know the details of the $ exchange between ROVI and the affiliates that host their hardware. I assume ROVI must be paying for the privilege, but one wonders whether many of the Tech Directors at the affiliates will consider the presumed monthly checks from ROVI to be large enough to compensate them for all the frustration the ROVI encoders seem to cause at several stations across the country. Also have to wonder whether the presumably meager ad revenue that ROVI derives from selling ad space on their EPG (for licensed software users) is enough to compensate them for their even larger bucket of frustration. Taken together, I think those two issues and the ever-shrinking population of OTA viewers spell the end of the TVGOS datastream in the not-too-distant future. If/when the ROVI encoders go dark, at least that will release "TV Guide Time Lock" on the DTVPal and owners will still be able to use them in PSIP or manual clock mode. Unfortunately, Sony DVG units will become "boat anchors" at that point.

True, but bear in mind:

1) The only true "freeloaders" using the TVGOS OTA data are owners of the DTVPal and Sony DVRs. Combined they represent such a tiny percentage (actually better expressed in ppm!) of the viewing audience that I strongly doubt the number-crunchers are even aware of them, much less considering them when determining business models.

2) A much larger (but still fairly small) group of OTA viewers make use of the TVGOS data on "approved devices" (mostly TVs). These people are subjected to ads on their guide displays and hence are not "freeloaders", but rather are paying their own way. Also these people are not using DVRs so they don't have the ability to skip through commercials and hence are not a threat to the ad revenue in anyone's business model. Readers of this thread are like the fleas that ride on the birds that ride around on the backs of elephants. No other creatures on the Serengeti give them much thought...

I agree it would be interesting to know the details of the $ exchange between ROVI and the affiliates that host their hardware. I assume ROVI must be paying for the privilege, but one wonders whether many of the Tech Directors at the affiliates will consider the presumed monthly checks from ROVI to be large enough to compensate them for all the frustration the ROVI encoders seem to cause at several stations across the country. Also have to wonder whether the presumably meager ad revenue that ROVI derives from selling ad space on their EPG (for licensed software users) is enough to compensate them for their even larger bucket of frustration. Taken together, I think those two issues and the ever-shrinking population of OTA viewers spell the end of the TVGOS datastream in the not-too-distant future. If/when the ROVI encoders go dark, at least that will release "TV Guide Time Lock" on the DTVPal and owners will still be able to use them in PSIP or manual clock mode. Unfortunately, Sony DVG units will become "boat anchors" at that point.

Good point.
Just wondering: Are the DMAs, having issues, in larger population areas?
NY is surely in one of the big areas. I'm in the large Indy DMA, but no issues here yet...fingers crossed. Seems like I remember a DMA in Texas also having an issue at one time.
I guess I'm just assuming a cash-strapped station would have less incentive to correct an issue that advertisers might see as costing them money.

Thanks for Your Time,

I am sure that ROVI pays the stations to insert the data and ROVI makes their money (if any) by charging hardware manufactures for the software and advertisers for the ads.

As far as I know Echostar is the only outfit that has a license to use the TVGOS stream without paying for the software and the logo.

There are a lot of older devices like my DMR-E85 and a lot of TVs that have TVGOS software that do not appear on the "supported list".

I usually vary from good enough to 7 minutes slow but normally it is 7 minutes slow. My theory is that the time issue is a result of ROVI not knowing how to integrate with all the different exciters across the country. For example it I use a Cincinnati zip code the time is always good but the listings are not for my local stations.

As for why some stations are dropping TVGOS I suspect they have determined that it is just not worth the hassle of listening to us complain. They may not be getting that many complaints however since only DVR users care about the time since most people have cable and depend on that for their EPG.

True, but bear in mind:

1) The only true "freeloaders" using the TVGOS OTA data are owners of the DTVPal and Sony DVRs. Combined they represent such a tiny percentage (actually better expressed in ppm!) of the viewing audience that I strongly doubt the number-crunchers are even aware of them, much less considering them when determining business models.


The Sony DHGs are not freeloaders. The Sonys use the official Gemstar (now Rovi) guide. Sony paid Gemstar to use their guide in the Sonys. This was during the days of analog TVGOS. Although Sony did as good as they could to try to support the digital TVGOS, they fell a little short. Sony discontinued the DHG even before digital TVGOS was being sent out. After getting reports that Sony users were having issues with the digital TVGOS data, and noone at Sony was left to work on the problem, Rovi found it easier to tell Sony users that their DVRS were no longer supported.

As far as Rovi's claim that no approved TVGOS device has this clock issue, I just don't believe that is true. The problem is that the only other TVGOS devices out there are TVs, and if your clock is off on your TV by 6 to 10 minutes, who cares? They aren't going to call Rovi and complain about something like that. Although I know a few people with TVGOS TVs, I don't know anyone who is in the Washington DC area, or I would verify this myself. I just don't believe that a device that has to rely on clock updates from TVGOS, also has the ability to ignore the updates if it feels like they are in error. Especially since the Sony is running the official Gemstar software, but apparently does not have such logic in its code. I just don't believe the logic exists in any of Gemstar's code.

Mark

The Sony DHGs are not freeloaders. The Sonys use the official Gemstar (now Rovi) guide. Sony paid Gemstar to use their guide in the Sonys. This was during the days of analog TVGOS. Although Sony did as good as they could to try to support the digital TVGOS, they fell a little short. Sony discontinued the DHG even before digital TVGOS was being sent out. After getting reports that Sony users were having issues with the digital TVGOS data, and noone at Sony was left to work on the problem, Rovi found it easier to tell Sony users that their DVRS were no longer supported.

I stand corrected. I thought the analog version of the Sony firmware was licensed (and thus included ads in the EPG) and the newer digital version of the Sony firmware was unlicensed (and thus did not have any ads in the EPG).


As far as Rovi's claim that no approved TVGOS device has this clock issue, I just don't believe that is true. The problem is that the only other TVGOS devices out there are TVs, and if your clock is off on your TV by 6 to 10 minutes, who cares? They aren't going to call Rovi and complain about something like that. Although I know a few people with TVGOS TVs, I don't know anyone who is in the Washington DC area, or I would verify this myself. I just don't believe that a device that has to rely on clock updates from TVGOS, also has the ability to ignore the updates if it feels like they are in error. Especially since the Sony is running the official Gemstar software, but apparently does not have such logic in its code. I just don't believe the logic exists in any of Gemstar's code.

Mark

Agree 100%. It would have had to have been some pretty good logic to discard the skewed timestamps that were being sent out for 19 hours out of every 24. I made that point to the ROVI rep back during the Austin issue, and his response was that the ROVI tech who actually stood in the local affiliate studio and looked at the clock display on a TVGOS-licensed TV saw perfect time during this period. I commented at the time (in this forum, not to him) that I didn't believe his story, but I had no way to disprove it.

The Sony DHGs are not freeloaders. The Sonys use the official Gemstar (now Rovi) guide. Sony paid Gemstar to use their guide in the Sonys. This was during the days of analog TVGOS. Although Sony did as good as they could to try to support the digital TVGOS, they fell a little short. Sony discontinued the DHG even before digital TVGOS was being sent out. After getting reports that Sony users were having issues with the digital TVGOS data, and noone at Sony was left to work on the problem, Rovi found it easier to tell Sony users that their DVRS were no longer supported.

As far as Rovi's claim that no approved TVGOS device has this clock issue, I just don't believe that is true. The problem is that the only other TVGOS devices out there are TVs, and if your clock is off on your TV by 6 to 10 minutes, who cares? They aren't going to call Rovi and complain about something like that. Although I know a few people with TVGOS TVs, I don't know anyone who is in the Washington DC area, or I would verify this myself. I just don't believe that a device that has to rely on clock updates from TVGOS, also has the ability to ignore the updates if it feels like they are in error. Especially since the Sony is running the official Gemstar software, but apparently does not have such logic in its code. I just don't believe the logic exists in any of Gemstar's code.

Mark

Sounds quite reasonable. I always assume that Rovi is full of crap.

Unfortunately I don't get the Bal'more stations with my little old Zenith antenna, so I can't try that route. Guess I'm out of luck. Although I'm somewhat amazed that this unit still works in any form.

I'm resetting the guide with a different zip, but I don't expect that to do anything.

I stand corrected. I thought the analog version of the Sony firmware was licensed (and thus included ads in the EPG) and the newer digital version of the Sony firmware was unlicensed (and thus did not have any ads in the EPG).


The digital version of the guide also has ads. Actually there is no visible difference between the digital guide, and analog guide. The only difference is how the data is delivered to the DVR. A lot of people have no idea whether they get the data from a digital channel, or through an analog cable channel.

Mark

Currently I have the update time set to 6:55 PM. This came from the discussion and recommendations on this subject last year, but I have not personally proven that this time is optimum.

That is a good time. Anytime after 6:25 pm should work. I thought there might be people who record things in the 6:00pm to 7:00pm timeslot, and wouldn't want the DVR rebooting on them during the recording (if it was recording something I'd think that it would skip the update check/reboot). That is why I looked at the 5:30pm time as an option. At 5:30pm, the TVGOS time should be caught back up, but then the last download of the day goes from 5:31pm - 6:16pm, and after that the TVGOS time would be off by about 7 minutes (based on the WHIO data that was posted).

If you check your DVR time at 6:30 pm (before the update check at 6:55) is the clock correct? From what I remember other people saying, the one update reboot kept the clock correct for the next 24 hours. Just wondered if that is still true.

Mark

As a general point of information, after TVGOS data resumed flowing the other day here in Philly, rebooting the DTVPal DVR by momentarily pulling its plug did NOT result in the TVGOS logo returning to the guide (I waited a full 24 hours); however, doing a factory reset DID result in return of the TVGOS logo within a 12 hour period, and return of all listings within a 24 hour period. Thus I conclude that the only reliable method of getting TVGOS back on this machine after an extended outage is by doing a factory reset (no big deal because the reset does not erase existing recordings.)

As a general point of information, after TVGOS data resumed flowing the other day here in Philly, rebooting the DTVPal DVR by momentarily pulling its plug did NOT result in the TVGOS logo returning to the guide (I waited a full 24 hours); however, doing a factory reset DID result in return of the TVGOS logo within a 12 hour period, and return of all listings within a 24 hour period. Thus I conclude that the only reliable method of getting TVGOS back on this machine after an extended outage is by doing a factory reset (no big deal because the reset does not erase existing recordings.)

Thanks for the info and let us know if TVGOS stays operational in your market! It was up in NYC for a few days and we have lost it again. So it will be interesting to see what happens in Philly.

Did you try the reset with the remote too?

That is a good time. Anytime after 6:25 pm should work. I thought there might be people who record things in the 6:00pm to 7:00pm timeslot, and wouldn't want the DVR rebooting on them during the recording (if it was recording something I'd think that it would skip the update check/reboot). That is why I looked at the 5:30pm time as an option. At 5:30pm, the TVGOS time should be caught back up, but then the last download of the day goes from 5:31pm - 6:16pm, and after that the TVGOS time would be off by about 7 minutes (based on the WHIO data that was posted).

If you check your DVR time at 6:30 pm (before the update check at 6:55) is the clock correct? From what I remember other people saying, the one update reboot kept the clock correct for the next 24 hours. Just wondered if that is still true.

Mark

I've not been checking the clock accuracy nearly as often as I did when the problem was at its peak last year. However when I do look at it just prior to the auto update time, often it is off by a few minutes (but this error is less than it once was). For me the clock "fix" has been two things: doing auto updates, and setting recordings to always start early and/or end late. These are obviously band-aid fixes, but they are the only tools I have under my control. And they are not always sufficient. Every so often we still miss the very beginning of shows.

I do not necessarily believe that the clock is accurate for 24 hours after updating. I suspect that updates make it "good enough" for that evenings' recordings, but that it probably drifts continuously until the next update. Obviously I could track this more closely, but last year's events have me rather burned out on the matter!

One last thing.... Now that Channel Master is selling a new version of the DVR, I wonder if anyone has noticed whether its clock accuracy is improved? During last year's discussions about the clock, fingers were pointed at WUSA Ch 9, Rovi, TVGOS, etc., but also at possible problems with the operating system within the CM7000PAL. If the latter was truly so, maybe the new DVR is better in this regards?

One last thing.... Now that Channel Master is selling a new version of the DVR, I wonder if anyone has noticed whether its clock accuracy is improved?
This is off topic for this thread. That said, the new 7400 gets its time from an Internet connection,
and reports in its thread are that the time is spot on.

...
One last thing.... Now that Channel Master is selling a new version of the DVR, I wonder if anyone has noticed whether its clock accuracy is improved? During last year's discussions about the clock, fingers were pointed at WUSA Ch 9, Rovi, TVGOS, etc., but also at possible problems with the operating system within the CM7000PAL. If the latter was truly so, maybe the new DVR is better in this regards?
I've been given an answer same question:

It's absolutely same HW and FW F2.08 = F4.00 (with changes in lines of "DTV Pal DVR" to "CM7000-PAL").

[...]
One last thing.... Now that Channel Master is selling a new version of the DVR, I wonder if anyone has noticed whether its clock accuracy is improved? During last year's discussions about the clock, fingers were pointed at WUSA Ch 9, Rovi, TVGOS, etc., but also at possible problems with the operating system within the CM7000PAL. If the latter was truly so, maybe the new DVR is better in this regards?

From what I have read their new DVR (7400) uses PSIP data by default, or you can pay somewhere between $50.00 to $100.00/year to receive some other guide, which isn't TVGOS.

Mark

From what I have read their new DVR (7400) uses PSIP data by default, or you can pay somewhere between $50.00 to $100.00/year to receive some other guide, which isn't TVGOS.

Mark

There are some heat issues with this device. So it may not be ready for prime time. Regarding the guide. Yes it does appear that it uses an internet connection to get a subscription 14 day guide for around $49. However I read some user reviews of this product where people said they did not connect to the internet and received a 7 day guide...must be TVGOS.

There are some heat issues with this device. So it may not be ready for prime time. Regarding the guide. Yes it does appear that it uses an internet connection to get a subscription 14 day guide for around $49. However I read some user reviews of this product where people said they did not connect to the internet and received a 7 day guide...must be TVGOS.
The way I read it it was a PSIP fluke, not TVGOS. :p

The way I read it it was a PSIP fluke, not TVGOS. :p

I would tend to agree. I guess we need info on how long that lasted and does it still exist.

This is off topic for this thread. That said, the new 7400 gets its time from an Internet connection,
and reports in its thread are that the time is spot on.

Thanks for this info. Sounds interesting!

I've been given an answer same question:

It's absolutely same HW and FW F2.08 = F4.00 (with changes in lines of "DTV Pal DVR" to "CM7000-PAL").

Others are saying that the 7400 gets (or can get) its time update via the internet, and that it may have an alternative source for the TV show info. Maybe it's too new a DVR to know these things yet.

From what I have read their new DVR (7400) uses PSIP data by default, or you can pay somewhere between $50.00 to $100.00/year to receive some other guide, which isn't TVGOS.

Mark

From the tests last year, I would sure prefer to have my clock set via PSIP instead of TVGOS. However since I own two CM7000PALs, I'm kind of stuck with that technology. Who knows, maybe CM will update the FW and make using PSIP a user option (oh sure -- I won't hold my breath until then).

From the tests last year, I would sure prefer to have my clock set via PSIP instead of TVGOS. However since I own two CM7000PALs, I'm kind of stuck with that technology. Who knows, maybe CM will update the FW and make using PSIP a user option (oh sure -- I won't hold my breath until then).If you disable TVGOS in the 7000PAL, it'll surely use PSIP for time (averaging times across stations, and throwing away obvious outlyers, as I understand the latest firmware does.) If you want TVGOS for listings, and PSIP for time, I guess you're out of luck.

TVGOS still working with your PALDVR in Philly? How long has it been working?

If you disable TVGOS in the 7000PAL, it'll surely use PSIP for time (averaging times across stations, and throwing away obvious outlyers, as I understand the latest firmware does.) If you want TVGOS for listings, and PSIP for time, I guess you're out of luck.

Actually you can't just "disable" TVGOS, except by removing the TVGOS station.

If you disable TVGOS in the 7000PAL, it'll surely use PSIP for time (averaging times across stations, and throwing away obvious outlyers, as I understand the latest firmware does.) If you want TVGOS for listings, and PSIP for time, I guess you're out of luck.

On the PAL if if finds TVGOS it uses it for time. All you can turn off is the EPG. At least that is the way mine seems to work.

Can someone explain to me why used DTVpals are selling for over $200 on Ebay?

This box was pre-sold by Dish for $250. Then sold for $300, Then Sears fire-sale them for $75 to $150 (New)

So why is a used box worth more then a SEARS fire-sale?

Can someone explain to me why used DTVpals are selling for over $200 on Ebay?

This box was pre-sold by Dish for $250. Then sold for $300, Then Sears fire-sale them for $75 to $150 (New)

So why is a used box worth more then a SEARS fire-sale?You answered your own question when you wrote Ebay. There are a lot buyers on there one would not classify as smart-shoppers.

On the PAL if if finds TVGOS it uses it for time. All you can turn off is the EPG. At least that is the way mine seems to work.
That has been my experience as well.

You answered your own question when you wrote Ebay. There are a lot buyers on there one would not classify as smart-shoppers.

Well I can not seem to find anywhere else that they are selling. You would think people would do DD and see what the retail price was.

A used one should be half of Retail or lower. That would be $100 to $150

$200 is half of $400, the cost of a new 7400. For some people, that may make a lot of sense.

$200 is half of $400, the cost of a new 7400. For some people, that may make a lot of sense.

The 7400 has more to offer. Such as internet and a better guide for $50 per year

Actually you can't just "disable" TVGOS, except by removing the TVGOS station.Actually Menu|Preferences|Guide Display|TVGuide Disable will disable it, but what I am hearing here is that even if you do that, the unit will still unequivocally snatch the time from an active TVGOS host (correct or off) rather than average times from all stations.

I hadn't known that for 2 reasons: 1) I always use the TVGOS time except while TVGOS is down; and 2) here in Philly the TVGOS time has always been (to my knowledge) correct or no more than a minute +/-.

TVGOS still working with your PALDVR in Philly? How long has it been working?I wasn't home when it came back, but my wife reported that my Sony DVR regained correct time late Friday afternoon. My DTVPal DVR needed a factory reset to recover TVGOS listings, which I did on Sunday afternoon, so it's been working (i.e. had a TVGuide logo) since Sunday but the listings didn't populate fully until about Tuesday afternoon.

I wasn't home when it came back, but my wife reported that my Sony DVR regained correct time late Friday afternoon. My DTVPal DVR needed a factory reset to recover TVGOS listings, which I did on Sunday afternoon, so it's been working (i.e. had a TVGuide logo) since Sunday but the listings didn't populate fully until about Tuesday afternoon.

Keep us posted if it stays up! I should email CBS NY and tell them their Philly station has figured out how to transmit TVGOS!

Well I can not seem to find anywhere else that they are selling. You would think people would do DD and see what the retail price was.

A used one should be half of Retail or lower. That would be $100 to $150

Obviously you have very little personal experience with buying & selling on Ebay. Often times, discontinued items can even sell for well over whatever their original MSRP was. Because it's not at all unusual for popular discontinued items to sell for high prices, many Ebay sellers thrive on the fact that they are often the last resort for finding and buying those kind of items.

Obviously you have very little personal experience with buying & selling on Ebay. Often times, discontinued items can even sell for well over whatever their original MSRP was. Because it's not at all unusual for popular discontinued items to sell for high prices, many Ebay sellers thrive on the fact that they are often the last resort for finding and buying those kind of items.

Ok, I was saying the people who are buying the DTVpal are fools. The price on the one up their now is $280 plus shipping. That is the same as Retail price. For a used and maybe broken item. That has no return policy. So the auction states.

Man I should of purchased 10 at Sears

From the tests last year, I would sure prefer to have my clock set via PSIP instead of TVGOS.

On the PAL if if finds TVGOS it uses it for time. All you can turn off is the EPG. At least that is the way mine seems to work.

The other day, I posted this solution here... (http://www.avsforum.com/avs-vb/showthread.php?p=21545999#post21545999)

The only way I know of to get manual control of the time back, is to do a Factory Default from the menu (this is not the same thing as holding the power button for 10 seconds, or unplugging and replugging the DTVPal). After doing the Factory Default, do not set a zip code (leave it at 00000). You will now have full manual control for setting the clock, however you will no longer receive TVGOS data, and you will only see the PSIP guide on your DTVPal.

Warning, boring TVGOS talk ahead...
The reason this works is that in order to take over the clock, the host channel has to send a "timezone packet" to the TVGOS device. This timezone packet tells the TVGOS device how far to offset the clock from GMT time for your local time (you set the timezone in the DTVPal menu, but TVGOS does not use this information). In order to deliver the timezone packet, the TVGOS device must know that the data being sent out by the host channel is for it. To do this the TVGOS device receives a zip code packet from the host channel. If the zip code entered into the TVGOS device matches the information in the zip code packet, then (and only then) will the TVGOS device accept a timezone packet from this host channel. If the zip code doesn't match, the TVGOS device will continue looking for a host channel that does match the TVGOS device's zip code. Once the timezone packet is successfully delivered to the DTVPal, the only way I know of to get rid of it, is with a Factory Default. The only way to prevent a timezone packet from being delivered in the first place, is to enter a zip code outside of the host channel's DMA (zip code 00000 works nicely).

Mark

Keep us posted if it stays up! I should email CBS NY and tell them their Philly station has figured out how to transmit TVGOS!

I'm again receiving TVGOS listings from CBS NYC on two different types of devices; hopefully it continues this time.

If you disable TVGOS in the 7000PAL, it'll surely use PSIP for time (averaging times across stations, and throwing away obvious outlyers, as I understand the latest firmware does.) If you want TVGOS for listings, and PSIP for time, I guess you're out of luck.

Right, and the latter is exactly what is needed when the clock setting becomes faulty. It's a shame that the manufacturer seems to have zero interest in tweaking the FW to add this seemingly obvious option.

Better yet - since it has an ethernet port - use an NTP source for time ?

The other day, I posted this solution here... (http://www.avsforum.com/avs-vb/showthread.php?p=21545999#post21545999)

The only way I know of to get manual control of the time back, is to do a Factory Default from the menu (this is not the same thing as holding the power button for 10 seconds, or unplugging and replugging the DTVPal). After doing the Factory Default, do not set a zip code (leave it at 00000). You will now have full manual control for setting the clock, however you will no longer receive TVGOS data, and you will only see the PSIP guide on your DTVPal.

Warning, boring TVGOS talk ahead...
The reason this works is that in order to take over the clock, the host channel has to send a "timezone packet" to the TVGOS device. This timezone packet tells the TVGOS device how far to offset the clock from GMT time for your local time (you set the timezone in the DTVPal menu, but TVGOS does not use this information). In order to deliver the timezone packet, the TVGOS device must know that the data being sent out by the host channel is for it. To do this the TVGOS device receives a zip code packet from the host channel. If the zip code entered into the TVGOS device matches the information in the zip code packet, then (and only then) will the TVGOS device accept a timezone packet from this host channel. If the zip code doesn't match, the TVGOS device will continue looking for a host channel that does match the TVGOS device's zip code. Once the timezone packet is successfully delivered to the DTVPal, the only way I know of to get rid of it, is with a Factory Default. The only way to prevent a timezone packet from being delivered in the first place, is to enter a zip code outside of the host channel's DMA (zip code 00000 works nicely).

Mark

Instead of using the Factory Default menu option, would the same results happen by manually adjusting the Zip Code to 00000? If so, at least the user wouldn't lose all their custom menu settings by employing the Factory Default.

Some TV sets use PSIP to get a small amount of show listings, 24 hours worth, I believe. However the DTVPal will not display the PSIP show listings if TVGOS is effectively disabled, correct?

Some TV sets use PSIP to get a small amount of show listings, 24 hours worth, I believe. However the DTVPal will not display the PSIP show listings if TVGOS is effectively disabled, correct?In my experience, the DTVPal DVR displays PSIP guide data for any station it cannot get TVGOS data for (including quite a few for which TVGOS data exists, but due to issue 6, are not picked up by the DVR). If a station is not transmitting any PSIP guide data, then there would be no listings for that station in the absence of TVGOS data.

I'm again receiving TVGOS listings from CBS NYC on two different types of devices; hopefully it continues this time.

However my 2 devices are still waiting to pick it up! I just did a soft reset and a factory reset and nothing so far.

Instead of using the Factory Default menu option, would the same results happen by manually adjusting the Zip Code to 00000? If so, at least the user wouldn't lose all their custom menu settings by employing the Factory Default.

[...]


Just setting the zip to 00000 won't work, because TVGOS has already delivered a timezone packet, and locked the time. The TVGOS timezone information must be cleared from the DVR, before you can get control of the clock. A Factory Default is the only way I know of to accomplish this. There is a chance, as Frank70 pointed out, that after 8 days without TVGOS and the TV Guide Logo goes away, it may also release the clock, but who wants to wait that long to get control of their clock back.

Mark

One of my PALDVRS is now showing the TVGUIDE logo so I can also confirm it seems to be back in the NYC area. I'm waiting to see when and if the other unit picks it up.

Man I should of purchased 10 at Sears

And you don't think that there were not people that did just that, bought a bunch from Sears and turned right around and put them up for sale on Ebay? There sure was! That is not at all a unusual tactic that many Ebay sellers do when they find out certain items are being discontinued, and they can grab a bunch of them for blow out pricing only to resell them on Ebay.

Just setting the zip to 00000 won't work, because TVGOS has already delivered a timezone packet, and locked the time. The TVGOS timezone information must be cleared from the DVR, before you can get control of the clock. A Factory Default is the only way I know of to accomplish this. There is a chance, as Frank70 pointed out, that after 8 days without TVGOS and the TV Guide Logo goes away, it may also release the clock, but who wants to wait that long to get control of their clock back.

Mark

I asked this question based on previous tests where local users changed their Wash DC area zip code setting to one in the Baltimore area in order to force the DVR to use that CBS affiliate and so get an accurate clock setting (at least for those users who could receive a solid signal from Baltimore). Maybe I am misremembering, but I thought the effect on the clock from this change was virtually immediate (well, overnight). Anyway, so I thought the change to 00000 might be similar, but evidently not. I don't really understand all the details of how TVGOS and the DVR interact, so thanks for the explanation.

I asked this question based on previous tests where local users changed their Wash DC area zip code setting to one in the Baltimore area in order to force the DVR to use that CBS affiliate and so get an accurate clock setting (at least for those users who could receive a solid signal from Baltimore). Maybe I am misremembering, but I thought the effect on the clock from this change was virtually immediate (well, overnight). Anyway, so I thought the change to 00000 might be similar, but evidently not. I don't really understand all the details of how TVGOS and the DVR interact, so thanks for the explanation.

Actually you could use the 00000 zip code set to get a correct clock, if you changed the zip code in the evening when there was no clock skew present. Making the assumption that the DTVPal version of TVGOS works exactly like the Gemstar version of TVGOS, the clock would then stay correct for at least 4 days. After 4 days the DTVPal would set the clock again, and there is no telling what time of day it would do this, so after 4 days of perfect time, your clock may suddenly be off by up to 7 minutes again.

Mark

WOW we are all rich. People on EBAy lost their minds

DTVPal DVR
US $422.00 current bid Plus $21 shipping

http://www.ebay.com/itm/ws/eBayISAPI.dll?ViewItem&item=110816821756&ssPageName=ADME:B:WNA:US:1123

I just got TVGOS to come back to my unit without reseting it or unplugging it.

I went into menu, setup, system setup then installation. From there I ran the setup wizard.

Just looked now and TVGOS guide data is back. I'm in NYC area using CBS-2.

I just got TVGOS to come back to my unit without reseting it or unplugging it.

I went into menu, setup, system setup then installation. From there I ran the setup wizard.

Just looked now and TVGOS guide data is back. I'm in NYC area using CBS-2.

Glad to hear it! I wanted to wait it out on both of my units and see if TVGOS would come back by itself but I got antsy and did factory resets.

Seems to me what you did is pretty close to doing a reset.

I hope now that it is back it stays back and they are not just testing!

Glad to hear it! I wanted to wait it out on both of my units and see if TVGOS would come back by itself but I got antsy and did factory resets.

Seems to me what you did is pretty close to doing a reset.

I hope now that it is back it stays back and they are not just testing!

Unfortunately, running the installation wizard is very close to a factory default. It would be nice to have a method to turn the TVGOS data on again (short of an actual firmware fix for this bug) that wouldn't wipe out all your timers.

Mark

Actually you could use the 00000 zip code set to get a correct clock, if you changed the zip code in the evening when there was no clock skew present. Making the assumption that the DTVPal version of TVGOS works exactly like the Gemstar version of TVGOS, the clock would then stay correct for at least 4 days. After 4 days the DTVPal would set the clock again, and there is no telling what time of day it would do this, so after 4 days of perfect time, your clock may suddenly be off by up to 7 minutes again.

Mark

Not good. It sounds like all I can try is to set the Zip code to Baltimore, fiddle with antenna bearing, and see what happens (again). Of course I can just sit back and hope that WUSA changes something in our favor. To that end, a few days ago I sent another email to the WUSA Tech Director, asking again about the clock problem. Frankly, it'll surprise me if he even replies.

Well I can not seem to find anywhere else that they are selling. You would think people would do DD and see what the retail price was.

A used one should be half of Retail or lower. That would be $100 to $150

Perhaps it is a case of supply and demand. If I have the only cup of water in 100 miles I can ask any price I want if you are thirsty.

I would not sell my DVR for less than the price of a lifetime TiVo but I would not buy another one because it is an orphan product.

I asked this question based on previous tests where local users changed their Wash DC area zip code setting to one in the Baltimore area in order to force the DVR to use that CBS affiliate and so get an accurate clock setting (at least for those users who could receive a solid signal from Baltimore). Maybe I am misremembering, but I thought the effect on the clock from this change was virtually immediate (well, overnight). Anyway, so I thought the change to 00000 might be similar, but evidently not. I don't really understand all the details of how TVGOS and the DVR interact, so thanks for the explanation.

Could be. If I change my zipcode to Cincinnati the clock is correct but I don't get local listing (except for PSIP). As best I can remember all I had to do was change the zip to 00000, put the DVR in standby for a while and then enter the new zip. For a while I would use a Dayton zip to get listings and then change to Cincinnati to have good time for a few days. Didn't do a factory reset.

Actually you could use the 00000 zip code set to get a correct clock, if you changed the zip code in the evening when there was no clock skew present. Making the assumption that the DTVPal version of TVGOS works exactly like the Gemstar version of TVGOS, the clock would then stay correct for at least 4 days. After 4 days the DTVPal would set the clock again, and there is no telling what time of day it would do this, so after 4 days of perfect time, your clock may suddenly be off by up to 7 minutes again.

Mark

Does not take 4 days, may be lucky to get 4 hours. I am not sure that every station stops sending TVGOS in the evening because I can do a soft reset before primetime and the logo usually comes back is less than an hour.

I am using my DISH DTV Pal plus dvr for recording primarily MeTv channel in the Beaumont,Tx area . Now London Broadcasting company does not put out psip or guide data at all on this station or MyTx their other sub channel. Even DISH themselves couldn't get them to budge on this issue, so we could get guide data for the station on the satellite either. I contacted them and they never respond to customer emails at all. But they did tell Kip Wilcoxson from DISH that they never received any complaints on not having guide data so why should they put out guide data. Since they don't respond to emails from their viewers I guess that means no guide info EVER.

But that being said , I wish they would allow me to edit and name my timers for the shows, so I could add the name of the show and then the show would record with the name on it . Instead I had to watch a little of the beginning of each show to tell what it was , before I could rename it the show it was. Seems like a simple fix to make the edit key to rename the timer to what I want , so it would record with the proper name.

I am using my DISH DTV Pal plus dvr for recording primarily MeTv channel in the Beaumont,Tx area . Now London Broadcasting company does not put out psip or guide data at all on this station or MyTx their other sub channel. Even DISH themselves couldn't get them to budge on this issue, so we could get guide data for the station on the satellite either. I contacted them and they never respond to customer emails at all. But they did tell Kip Wilcoxson from DISH that they never received any complaints on not having guide data so why should they put out guide data. Since they don't respond to emails from their viewers I guess that means no guide info EVER.

But that being said , I wish they would allow me to edit and name my timers for the shows, so I could add the name of the show and then the show would record with the name on it . Instead I had to watch a little of the beginning of each show to tell what it was , before I could rename it the show it was. Seems like a simple fix to make the edit key to rename the timer to what I want , so it would record with the proper name.
Contact the FCC. I think they are required by law to include up to 16 days of PSIP in their stream. Note I said up to, most stations only send 8 hours and they don't always move the 8 hour window so you may only get a few hours until they provide another block.

Whats required is a minimum of 12 hours.

Contact the FCC. I think they are required by law to include up to 16 days of PSIP in their stream. Note I said up to, most stations only send 8 hours and they don't always move the 8 hour window so you may only get a few hours until they provide another block.

+ 1 It is federal law

Does not take 4 days, may be lucky to get 4 hours. I am not sure that every station stops sending TVGOS in the evening because I can do a soft reset before primetime and the logo usually comes back is less than an hour.

TVGOS data is sent out 24/7, however listing data is only sent out for 25 minutes, 8 times a day between 1:00am and 5:00pm. It seems to be the detection of listing data in the DTVPal that triggers the TV Guide Logo.

The soft reset does not clear the DTVPal of TVGOS listings, they are still there. Initially the logo and listings go away, but will come back after a few minutes. You can also disconnect the antenna, and do the soft reset, and the logo will still come back after a few minutes. Apparently that logo just indicates that the DVR has some TVGOS listing data in it. It is not an indication that TVGOS listing data is actively coming in the antenna port.

Mark

Could be. If I change my zipcode to Cincinnati the clock is correct but I don't get local listing (except for PSIP). As best I can remember all I had to do was change the zip to 00000, put the DVR in standby for a while and then enter the new zip. For a while I would use a Dayton zip to get listings and then change to Cincinnati to have good time for a few days. Didn't do a factory reset.

I saw what you did after changing my zip code to another city -- an accurate clock but only one day of show listings (presumably via PSIP). However I'm not certain whether these effects were permanent.

Not good. It sounds like all I can try is to set the Zip code to Baltimore, fiddle with antenna bearing, and see what happens (again). Of course I can just sit back and hope that WUSA changes something in our favor. To that end, a few days ago I sent another email to the WUSA Tech Director, asking again about the clock problem. Frankly, it'll surprise me if he even replies.

I've pretty much left mine on Baltimore. Recordings constantly screwed up due to bad time was worse than not having the TV guide. Only occasionally do I need to reset (or add a new) timer.

I usually don't recording anything on Sat am thru Sun evening. I have considered changing zip code back at the beginning of the weekend and back at the end to attempt to pick up TVGOS data for the week - but just haven't messed with it yet.

I've pretty much left mine on Baltimore. Recordings constantly screwed up due to bad time was worse than not having the TV guide. Only occasionally do I need to reset (or add a new) timer.

I usually don't recording anything on Sat am thru Sun evening. I have considered changing zip code back at the beginning of the weekend and back at the end to attempt to pick up TVGOS data for the week - but just haven't messed with it yet.

I couldn't agree more that the main problem is missing part of recorded shows. That said, maybe I'll again try a Balt zip code.

The above makes me wonder (again) what Ch 9 is doing wrong that Ch 13 is doing right. Maybe it's significant that Ch 9 is wedging in their main channel plus 2 subchannels whereas Ch 13 has only the main channel. Last year someone mentioned bandwidth allocation as being a core problem, and this was when WUSA had only 9.1 and 9.2 as compared to the three they now have. If this in fact has an impact on the DVR clock problem, I can imagine which WUSA will chose when it comes to profit vs. TVGOS integrity.

I couldn't agree more that the main problem is missing part of recorded shows. That said, maybe I'll again try a Balt zip code.
The above makes me wonder (again) what Ch 9 is doing wrong that Ch 13 is doing right. Maybe it's significant that Ch 9 is wedging in their main channel plus 2 subchannels whereas Ch 13 has only the main channel. Last year someone mentioned bandwidth allocation as being a core problem, and this was when WUSA had only 9.1 and 9.2 as compared to the three they now have. If this in fact has an impact on the DVR clock problem, I can imagine which WUSA will chose when it comes to profit vs. TVGOS integrity.
============================================
Greetings,
A week or so ago, I had sent an email to the tech guy at WUSA (CBS-Wash., DC) and he said he was aware of the problem with the TVGOS time not being correct, but he was trying to get the problem resolved with ROVI. I also had sent an email to ROVI about the problem. I just got a reply from ROVI about this problem. I really don't understand why it is so technically difficult to get the basic but essential time to be correct so that the DVRs can start recording at the correct time. Beats me. But here is yesterday's reply from ROVI to my email:
-----
Hello Gary,
I am sorry that your clock is not showing the correct time again. This is an issue we are aware of, and our Engineers are working on a fix for this problem. While I do not have an exact date, we are hopeful that the issue will be resolved within the next few weeks. If your clock is not fixed after this time-frame, please let us know.
Thank you,
CE Technical Support
Rovi
-----
Gary

I couldn't agree more that the main problem is missing part of recorded shows. That said, maybe I'll again try a Balt zip code.

The above makes me wonder (again) what Ch 9 is doing wrong that Ch 13 is doing right. Maybe it's significant that Ch 9 is wedging in their main channel plus 2 subchannels whereas Ch 13 has only the main channel. Last year someone mentioned bandwidth allocation as being a core problem, and this was when WUSA had only 9.1 and 9.2 as compared to the three they now have. If this in fact has an impact on the DVR clock problem, I can imagine which WUSA will chose when it comes to profit vs. TVGOS integrity.

TVGOS was off probably at least 3 weeks here in El Paso TX, since I had already lost the logo. Sent an email to cbs station engineer and did a "factory reset" every couple of days and yesterday it was back. So i guess it is not gone everywhere.

The big problem stations have with multiple channels is the Bandwidth. It is a very delicate balance and almost all has to go to the HD Chanel, The -1 . If not enough is allocated you get a lot of pixilation. I wish they would just drop the .2,.3 and .4 instead of trying to be Macho and brag about how many they have and just give us all a great HD.

One of my three beloved DTVPal DVRs has just stopped working after barely any warning. Prior to that been perfect for almost 2 years since I bought it used.

Here's the chronology:
- last night, turned on the unit from standby and program guide appeared, but unit was frozen. Tried turning it off and on and unplugging/replugging a few more times before going to bed to no avail.
- now, tried turning it on again and this time, both the red and yellow lights light, no picture or audio, both lights go out and I can hear the hard drive spinning?

Anyone have this happen and if so, did they fix it and if so, how?

Thanks for the help!

- now, tried turning it on again and this time, both the red and yellow lights light, no picture or audio, both lights go out and I can hear the hard drive spinning?

I'd make sure that in your angst that you didn't change the input on the TV. Both lights coming on and off is the standard start up.

Given that the machine was used, did it have firmware F208 or a earlier version on it?

I'd make sure that in your angst that you didn't change the input on the TV. Both lights coming on and off is the standard start up.

Given that the machine was used, did it have firmware F208 or a earlier version on it?
Thanks for the help!

Had previously updated firmware on all my DTVPals to F208TALD-N.

Yes, checked the input to make sure and also then wondered about the HDMI input on the HDTV, which has been a bit glitchy with regard to audio lag and audio distortion in the past. Grabbed one of the other DTVPals and it works fine on the same HDTV in the same input using the same wiring as the one which now doesn't work anymore.

It almost seems like it wants to do one of those reboots that a DTVPal sometimes does when the HDD gets really full and freezes while in Guide... but it somehow now seems like it is stuck just before you see the DTV Pal download/resetting, please wait screen?

You might try leaving it unplugged overnight.

You might try leaving it unplugged overnight.

Okay, will do.
I'll report back tomorrow.

============================================
Greetings,
A week or so ago, I had sent an email to the tech guy at WUSA (CBS-Wash., DC) and he said he was aware of the problem with the TVGOS time not being correct, but he was trying to get the problem resolved with ROVI. I also had sent an email to ROVI about the problem. I just got a reply from ROVI about this problem. I really don't understand why it is so technically difficult to get the basic but essential time to be correct so that the DVRs can start recording at the correct time. Beats me. But here is yesterday's reply from ROVI to my email:
-----
Hello Gary,
I am sorry that your clock is not showing the correct time again. This is an issue we are aware of, and our Engineers are working on a fix for this problem. While I do not have an exact date, we are hopeful that the issue will be resolved within the next few weeks. If your clock is not fixed after this time-frame, please let us know.
Thank you,
CE Technical Support
Rovi
-----
Gary

Interesting. Checkout this email (http://www.avsforum.com/avs-vb/showthread.php?p=21610040#post21610040) that Rovi sent to someone on the Sony forum, it is much more specific, and makes it sound like they are going to do something very soon.

Mark

Messed around with my broken DTVPal DVR again tonight before unplugging it for the night and here is what I saw tonight.

Plugged it in, then I turned it on, the red and green light stayed on for about 8 seconds and then went off. The HD then started spinning.
Eventually the green light came back on, but I never got any image or sound from the HDTV. Strangely, I am able to turn the green light off and on with the remote. As far as I can tell, the HD is spinning all the time as it usually is.

Almost seems like the unit is working but there is something wrong with the units HDMI output. I know the HDTVs HDMI input is fine since I already tested that with another DVDPal DVR. Gonna try the other audio/video connections tomorrow and see if they work.

Thanks again to everyone who has helped me with suggestions via this thread and via PMs. :)

Messed around with my broken DTVPal DVR again tonight before unplugging it for the night and here is what I saw tonight.

Plugged it in, then I turned it on, the red and green light stayed on for about 8 seconds and then went off. The HD then started spinning.
Eventually the green light came back on, but I never got any image or sound from the HDTV. Strangely, I am able to turn the green light off and on with the remote. As far as I can tell, the HD is spinning all the time as it usually is.

Almost seems like the unit is working but there is something wrong with the units HDMI output. I know the HDTVs HDMI input is fine since I already tested that with another DVDPal DVR. Gonna try the other audio/video connections tomorrow and see if they work.

Thanks again to everyone who has helped me with suggestions via this thread and via PMs. :)
Your TV is set for HDMI. Please check your remote and make sure your TV is set to HDMI source.

Your TV is set for HDMI. Please check your remote and make sure your TV is set to HDMI source.
Thanks for your help in this thread and via PM.

Pulled the working DTVPal DVR from our gameroom and stuck it in the place of the DTVPal which isn't working and everything is fine... so the problem lies with the non-working unit. Haven't yet tried any of the other nonworking units a/v outputs yet except for HDMI though.

You could try swapping the hard drives between each unit. See if the problem follows the drive or the box. Maybe it's just a bad drive and would be the easiest repair. Just a thought.

Interesting. Checkout this email (http://www.avsforum.com/avs-vb/showthread.php?p=21610040#post21610040) that Rovi sent to someone on the Sony forum, it is much more specific, and makes it sound like they are going to do something very soon.

Mark
"physical change in the placement" of the ROVI hardware sounds like the same change ROVI proposed in Austin last year. They wanted to move their encoder from the "end of the line" to the "front of the line" in the ATSC daisy-chain. If this is the one and only solution that ROVI has to this problem at every affected affiliate across the country, I'd consider that pretty good confirmation of the working theory that says the ROVI encoders cannot deal with fully allocated ATSC bandwidth. They rely on significant "empty space" in the ATSC stream in order to work properly. Evidently they require more "empty space" than any other devices typically found in an affiliate's daisy-chain. I consider that a design flaw in the ROVI box. Fortunately for DC area viewers, WUSA seems to be willing to accomodate ROVI's work-around proposal as opposed to the response they got here from KEYE, "No way, come pick up your crap and get it out of here!"

All of our issues may be moot soon anyway according to some info I recently read. Apparently, congress is considering changing the frequencies used by OTA digital signals which would essentially make all our current ATSC tuner containing gear non-functional.

Anyone else hear about this and have more info than the little stuff I read about?

Here is a thread on this issue here on AVS: http://www.avsforum.com/avs-vb/showthread.php?t=1360668

"physical change in the placement" of the ROVI hardware sounds like the same change ROVI proposed in Austin last year. They wanted to move their encoder from the "end of the line" to the "front of the line" in the ATSC daisy-chain. If this is the one and only solution that ROVI has to this problem at every affected affiliate across the country, I'd consider that pretty good confirmation of the working theory that says the ROVI encoders cannot deal with fully allocated ATSC bandwidth. They rely on significant "empty space" in the ATSC stream in order to work properly. Evidently they require more "empty space" than any other devices typically found in an affiliate's daisy-chain. I consider that a design flaw in the ROVI box. Fortunately for DC area viewers, WUSA seems to be willing to accomodate ROVI's work-around proposal as opposed to the response they got here from KEYE, "No way, come pick up your crap and get it out of here!"
By technical language - assign higher priority for TVGOS PID 111/112 packets.
Not exactly "move" the encoder, but change settings in a muxer. Same time I would be questioning whole muxing system of the station(s) if it could create packet's delay measuring in MINUTES (!) and TTL is not set at all to clean such delays. Perhaps no network specialist working for these stations, then hire a contractor ! Ask colleagues who are serving same equipment in Bay Area !

Thanks for your help in this thread and via PM.

Pulled the working DTVPal DVR from our gameroom and stuck it in the place of the DTVPal which isn't working and everything is fine... so the problem lies with the non-working unit. Haven't yet tried any of the other nonworking units a/v outputs yet except for HDMI though.

To ask the obvious but have you tried component out or RF out to determine if it is just the port or there is no video decoding? Is it only when you play a recording or how about "live TV". I think both use the same decoder. Do you get a signal in analog pass through?

Not exactly "move" the encoder, but change settings in a muxer.

Are you sure that's the only possible infrastructure architecture at the affiliate? I have no idea, but I ask the question because of the following two comments during the Austin debug phase:

1) From ROVI and KEYE: The proposed solution involves relocating the ROVI encoder to a position further "upstream" in the KEYE infrastrucure.

2) From KEYE: "There is no MUX downstream of the ROVI encoder"

Just wondering if there are other possible arrangements possible at the affiliates and whether the ROVI encoder may not have been designed to live happily in some of those alternate environments...

============================================
Greetings,
A week or so ago, I had sent an email to the tech guy at WUSA (CBS-Wash., DC) and he said he was aware of the problem with the TVGOS time not being correct, but he was trying to get the problem resolved with ROVI. I also had sent an email to ROVI about the problem. I just got a reply from ROVI about this problem. I really don't understand why it is so technically difficult to get the basic but essential time to be correct so that the DVRs can start recording at the correct time. Beats me. But here is yesterday's reply from ROVI to my email:
-----
Hello Gary,
I am sorry that your clock is not showing the correct time again. This is an issue we are aware of, and our Engineers are working on a fix for this problem. While I do not have an exact date, we are hopeful that the issue will be resolved within the next few weeks. If your clock is not fixed after this time-frame, please let us know.
Thank you,
CE Technical Support
Rovi
-----
Gary

Right, and more or less those exact same words were said many months ago. For me anyway, to be told "we are working on it" just doesn't cut it after this long.

If we buy the old adage that "an exception breaks the rule", all we need do is to compare clock setting results using WUSA versus using WJZ in Baltimore. And in that, WJZ always wins. Is it simplistic to think that whatever Rovi/TVGOS hardware and software which works for one ought to work for the other? As for differences (if any) between the two stations, having zero inside information, all I can see is the obviously dissimilar sub-channel setup.

BTW, I still have not heard from WUSA. It looks like their Tech Director must think that one single sentence reply per year ought to be enough to satisfy an end user.

TVGOS was off probably at least 3 weeks here in El Paso TX, since I had already lost the logo. Sent an email to cbs station engineer and did a "factory reset" every couple of days and yesterday it was back. So i guess it is not gone everywhere.

The big problem stations have with multiple channels is the Bandwidth. It is a very delicate balance and almost all has to go to the HD Chanel, The -1 . If not enough is allocated you get a lot of pixilation. I wish they would just drop the .2,.3 and .4 instead of trying to be Macho and brag about how many they have and just give us all a great HD.

If pixelization is the main symptom to look for as regards improper bandwidth allocation, our local station must be doing things right. Maybe trying to do this along with wedging in the TVGOS info is just too much.

Interesting. Checkout this email (http://www.avsforum.com/avs-vb/showthread.php?p=21610040#post21610040) that Rovi sent to someone on the Sony forum, it is much more specific, and makes it sound like they are going to do something very soon.

Mark

That message is very strange, especially the part about "physical change to our hardware placement at the station". It almost sounds like some cable was too long -- how basic! :-)

That message is very strange, especially the part about "physical change to our hardware placement at the station". It almost sounds like some cable was too long -- how basic! :-)

Just kidding!

Just kidding!

The physical placement issue has to do with where the TVGOS date is inserted into the stations data stream. Apparently it can matter.

Ken, now you're kidding ... It's all packetizing of digital video/audio/digital streams and network kind of streaming/muxing where delays is microseconds and physical location inside of local network doesn't matter. That's why ROVI's box is co-locating at stations.

Ken, now you're kidding ... It's all packetizing of digital video/audio/digital streams and network kind of streaming/muxing where delays is microseconds and physical location inside of local network doesn't matter. That's why ROVI's box is co-locating at stations.Thanks for catching that one.

Not kidding, but definitely misspoke. The physical location is irrelevant. It's all about where the TVGOS data is added in the chain.

I can see some local station or cableco somewhere having an issue with where the hardware is, and having to figure out where to put stuff and where to run cables, but that would be totally unrelated to the issues at hand.

Thanks for catching that one.

Not kidding, but definitely misspoke. The physical location is irrelevant. It's all about where the TVGOS data is added in the chain.

I can see some local station or cableco somewhere having an issue with where the hardware is, and having to figure out where to put stuff and where to run cables, but that would be totally unrelated to the issues at hand.

Assuming the insertion point for the TVGOS data might be the problem at WUSA, the Wash DC CBS affiliate, does it make sense that the clock symptoms would have surfaced more or less overnight (I believe the problem began on same day as the spring DST shift in 2011)?

Also, attempting to get a better handle on what's going on, in general would it be a major issue to change the insertion point?

Hi, All,

I am located near Dayton, Ohio (WHIO Channel 7 area).

For the last several weeks the clock time on my DTVPal has been consistently 5-7 minutes behind the correct time. This causes the first several minutes of recorded programs to be missed.

I understand that there have been problems in this area in the past, but somehow I have never experienced the problem myself until the past 3 weeks or so.

As suggested in previous posts I can get the DTVPal clock temporarily reset to the correct time by scheduling an evening reboot. A reboot at 6:30PM keeps the clock correct through prime time, but by the next morning the clock has drifted and settled back to 5-7 minutes slow.

I believe the problem lies with the time signal sent out by the ROVI/TVGoS encoder at WHIO?


So I have two questions:


First, is anyone else in the WHIO/Dayton area currently noticing the problem, or might my own DTVPal be at fault?


Second (and I'm sure other folks might appreciate this as well), would it be possible for someone to neatly and concisely summarize the facts, causes and solutions for the clock drift problem into one nice post?

There is a lot of good info about the problem scattered through the >13900 posts in this thread, but I am still unsure exactly how the problem relates to ROVI, TVGOS, PSIP and how the time gets set on the DTVPal.

For instance: It is stated in the first post in this thread that once the time is corrected by a reboot that the drift will "reoccur when the channel with the incorrect time is tuned again". I find the drift reoccurs overnight no matter whether I have used the box that evening, or which channels I leave it tuned to overnight.


Anyway, I would welcome a nice simple summary of all that is known about the problem. The post could be placed into the Known Issues section of the initial post...


Thanks!

Ken

Assuming the insertion point for the TVGOS data might be the problem at WUSA, the Wash DC CBS affiliate, does it make sense that the clock symptoms would have surfaced more or less overnight (I believe the problem began on same day as the spring DST shift in 2011)?

Also, attempting to get a better handle on what's going on, in general would it be a major issue to change the insertion point?
I wouldn't discuss the ROVI's wording at all; I don't have exactly the stations' block diagram at least to make any conclusion.

For my, as EE/IT/network person, I see no meaning for the (embraced by ROVI) words "insertion point" or "physical location". At least before some engineer who is working with a muxer at OTA station will chime here or in PM.

Hi, All,

...

First, is anyone else in the WHIO/Dayton area currently noticing the problem, or might my own DTVPal be at fault?

...

Yes I have the same problem and ROVI is aware of it.

I wouldn't discuss the ROVI's wording at all; I don't have exactly the stations' block diagram at least to make any conclusion.

For my, as EE/IT/network person, I see no meaning for the (embraced by ROVI) words "insertion point" or "physical location". At least before some engineer who is working with a muxer at OTA station will chime here or in PM.

Reading between the lines I think all they are saying is that you can look at each packet as a little train of bins that passes through a warehouse and as it passes by people throw packages into the empty bins. The guy where the train leaves the warehouse has a poorer chance of finding an empty bin to put his package in, particulary if it is a large package. Now whether the order is determined by a priority system or a physical chain I don't know but I believe they are saying first come, first served and TVGOS is left looking for scrap space and as someone suggested there is no Time To Live tag on the data.

Reading between the lines I think all they are saying is that you can look at each packet as a little train of bins that passes through a warehouse and as it passes by people throw packages into the empty bins. The guy where the train leaves the warehouse has a poorer chance of finding an empty bin to put his package in, particulary if it is a large package. Now whether the order is determined by a priority system or a physical chain I don't know but I believe they are saying first come, first served and TVGOS is left looking for scrap space and as someone suggested there is no Time To Live tag on the data.

I admit I don't know how the data at the station works, but your analogy is exactly my perception of what is happening. I'll also add that the guy who can't find enough empty cars to put his packages in, has a stack of packages that keep piling up behind him. Some of those packages are used to tell the DTVPal what time it is. Since the packages aren't getting out of the warehouse in a timely fashion, by the time the DTVPal gets the "time" package, the information in it can be several minutes old. In the evening the number of packages that are added to the pile drops significantly allowing the guy to catch up.

Mark

I wouldn't discuss the ROVI's wording at all; I don't have exactly the stations' block diagram at least to make any conclusion.

For my, as EE/IT/network person, I see no meaning for the (embraced by ROVI) words "insertion point" or "physical location". At least before some engineer who is working with a muxer at OTA station will chime here or in PM.

My background is in circuit design, nothing to do with TV, etc. As you say, maybe someone versed in broadcast engineering will jump in an explain the details here in a way that a "plain" EE will understand.

I just noticed this problem today. I am in NYC metro area. My DVR showed 1 hour ahead. I re-set the machine and it got the clock as 1 hour ahead. To make matters worse BOTH times the program schedule showed 1 hour ahead therefore SNL shows as starting at 12:30 AM.

I just noticed this problem today. I am in NYC metro area. My DVR showed 1 hour ahead. I re-set the machine and it got the clock as 1 hour ahead. To make matters worse BOTH times the program schedule showed 1 hour ahead therefore SNL shows as starting at 12:30 AM.

That is because the start of Daylight Saving Time is exactly one month away.
The time should be back to the correct hour tomorrow. The PAL changes time on the day exactly one month before the time change then changes back until the actual change.

I just noticed this problem today. I am in NYC metro area. My DVR showed 1 hour ahead. I re-set the machine and it got the clock as 1 hour ahead. To make matters worse BOTH times the program schedule showed 1 hour ahead therefore SNL shows as starting at 12:30 AM.

Great this is payback for all the years of No serious TVGOS problems :D

I forced a reset I told it that we didnt observe DST and then I went back and said we did and then it got the correct time of day AND the guide loaded correct, except 11:00 - 12AM shows as 1 hour block, no SNL. Does ANYONE know why the guide info is not correct any more

I forced a reset I told it that we didnt observe DST and then I went back and said we did and then it got the correct time of day AND the guide loaded correct, except 11:00 - 12AM shows as 1 hour block, no SNL. Does ANYONE know why the guide info is not correct any more

Sounds like when you looked at it after the reset, that it was still showing PSIP data, which didn't go out that far, and it hadn't redisplayed the TVGOS data yet. It doesn't matter whether the guide info is correct or not, just make sure the timer shows the right start and end time.

Mark

Reading between the lines I think all they are saying is that you can look at each packet as a little train of bins that passes through a warehouse and as it passes by people throw packages into the empty bins. The guy where the train leaves the warehouse has a poorer chance of finding an empty bin to put his package in, particulary if it is a large package. Now whether the order is determined by a priority system or a physical chain I don't know but I believe they are saying first come, first served and TVGOS is left looking for scrap space and as someone suggested there is no Time To Live tag on the data.

OK, I could add something practical to your analogy.
- the speed is 100 Mbps at least (perhaps they using latest 1Gbps network), mux packet's size is fixed - 188 bytes, network's packet - 1500 bytes so delays are microseconds; also each network packet has TTL - time to live, so the packet cannot traveling or 'stashed' indefinitely (or that long as we speak about minutes).
Most likely (any broadcasting engineers out there ?) the ROVI box has some input port, what accept some cmds from station mux box - like "give me time-stamp" or "flood with your TVGOS data now" and the box is coming from sleep/standby mode for minutes instead of milliseconds. Speculations, speculations ...

OK, I could add something practical to your analogy.
- the speed is 100 Mbps at least (perhaps they using latest 1Gbps network), mux packet's size is fixed - 188 bytes, network's packet - 1500 bytes so delays are microseconds; also each network packet has TTL - time to live, so the packet cannot traveling or 'stashed' indefinitely (or that long as we speak about minutes).
Most likely (any broadcasting engineers out there ?) the ROVI box has some input port, what accept some cmds from station mux box - like "give me time-stamp" or "flood with your TVGOS data now" and the box is coming from sleep/standby mode for minutes instead of milliseconds. Speculations, speculations ...

Remember, when KEYE had this issue in Austin, Rovi replaced their inserter with a different one, and it didn't fix the problem. It isn't the inserter that is at fault here. The data from the inserter is being delayed somewhere, and it is late to be inserted into the signal.

After looking at all those TSReader logs, you should know that the inserter never sleeps, it is sending out data at least once a second 24 hours a day. Time packets get sent out every 15 seconds. If the inserter was sleeping, and not sending its data then there would be breaks in the TSReader logs. If you look at my analysis (http://www.avsforum.com/avs-vb/showthread.php?p=21019178#post21019178) of Nitewatchman's log from last September, you'll see there are no breaks in the log, but during the highest data rate downloads, the clock time slips about 9 seconds per minute. The longest download is 45 minutes, which would cause the clock time to lose approximately 7 minutes from start to finish of that download. There are no gaps. The clock does not just suddenly skip to being 5 minutes off. It is a gradual skew of the data. If it wasn't for the correct time stamps in the log file, you wouldn't even be able to tell that there was anything wrong. The data is just being held up enough (about 150 milliseconds every second), that over the course of one download, the clock data can be off several minutes.

Mark

That is because the start of Daylight Saving Time is exactly one month away.
The time should be back to the correct hour tomorrow. The PAL changes time on the day exactly one month before the time change then changes back until the actual change.

This is a problem with the time information sent out by the station. There are fields in the system time table indicating when the change will happen. The problem is that this includes a day of month but not month of year. So when the twits update the system time table on 11 Feb. the receiver has no way of knowing that 11 is 11 Mar. and not 11 Feb.

I did a survey of the local stations here that ought to know better and only 3 out of 11 stations aren't off by an hour. I contacted all of them last fall to complain and since that didn't help, this time I went to the FCC web site and filled out the complaint form.

While I confess to not understanding much of what you folks are taling about with muxes, TSreaders etc. I sure do appreciate your trying to help us and address issues with the various stations out there (even though I haven't had time issues). It's really nice to know there are folks out there who are trying to help us OTA users, they take the time to investigate and explain, and we have a forum to communicate on.

So thanks AVS Forum too!

Remember, when KEYE had this issue in Austin, Rovi replaced their inserter with a different one, and it didn't fix the problem. It isn't the inserter that is at fault here. The data from the inserter is being delayed somewhere, and it is late to be inserted into the signal.

Exactly. At that point in the Austin debug phase, we all concluded that the timestamps are being buffered either internally in the ROVI box or at some MUX downstream of the ROVI box. When I communicated these conclusions to the Tech Director at KEYE, he replied that there is no MUX or any other kind of buffer downstream of the ROVI box in the KEYE infrastructure. Taking him at his word, the only remaining conclusion is that the ROVI box is buffering the timestamps internally when there is insufficient bandwidth available to insert them in real time. This means:

1) The design of the ROVI encoder is flawed. It should never respond to insufficient ATSC bandwidth by inserting skewed timestamps. They should either be inserted real-time or omitted.

2) It is easy to understand how this problem can mysteriously appear/disappear at various affiliates around the country. If their infrastructure is setup similar to KEYE's, the only input variable necessary to trigger/cure the clock skew issue is for their ATSC bandwidth utilization to increase/decrease. That could result from any number of changes that the station might make at any time.

I'm agree, my last idea was not totally correct, but let me speculate little more:
- that's correct, there is regular inserting TVGOS [wrong or correct] time stamps [ts] by the [ROVI] box (I should got it first as seen many logs by myself);
- in some locations sometimes the ts values of properly inserted TVGOS packets are skewed (delayed or advanced);
- deduct from above: the box is functioning correctly as an 'inserter' of packets regardless available bandwidth, and station equipment allow it do the job;
- I'm still thinking about station control signals to the box: sort of sync or 'ticks' ...

If someone would tell us - is the 'black' box has some control/sync input from station's equipment ? Time sync packets ?
If ROVI would enlighten us - how the box keep time in sync ? By NTP from Internet sites ? By time packets from station equipment ? By own timekeeper chip ?
Most likely the issue somewhere here - time sync method, input control signals ...

I don't recall exactly, but I believe the KEYE Tech Dir told me that the ROVI box interface is very simple, "just hook it up, and plug it in" with no control or clock inputs or parameters to be set by the station at all, a pure "black box" as far as they're concerned. So since we're all speculating here's my best guess at what's going on:

ROVI supplies the encoder to the station and tells them that they have two choices regarding how to install it:

1) DISCRETE (dedicated bandwidth) mode: This is the mode P Smith has been describing. In this mode, the ROVI box has only 3 connections to the outside world, AC power, Ethernet, ATSC-Out. It gets ALL external data including and required clock references from the ROVI mothership via the ethernet connection. The ATSC-Out feeds an INPUT to the station MUX which must be configured to allocate a certain amount of bandwidth to the ROVI box (as well as every other data source that is feeding it).

2) INLINE (scavenger bandwidth) mode: In this mode there are the three exernal connections listed above plus a fourth; ATSC-In. In this configuration, the OUTPUT of the station MUX feeds the ATSC-In connection of the ROVI box (ie ROVI box is "downstream" of the station MUX). ATSC-Out from the ROVI box presumably feeds straight into the station transmitter. In this mode, the station MUX does not allocate any specific bandwidth for the ROVI box which then has to act as a "scavenger" trying to shove data into any available empty space in the ATSC stream (like the boxes being packed into the train cars of the previous analogy).

To a station Tech Dir trying to maximize HD-PQ or subchanels (or both), INLINE mode would have a certain appeal. It would leave him with a little extra bandwidth that he could use for other purposes. So here is what I think is happening nation-wide:

- Some stations have installed the ROVI box in DISCREET mode. These stations have never (and will never) see the clock skew issue.

- Some stations have installed the ROVI box in INLINE mode, but (to date) have not fully allocated their ATSC bandwidth. These stations have not seen the clock skew issue SO FAR, but they are vulnerable to it in the future if they add more subchannels or try to increase PQ.

- Some stations have installed the ROVI box in INLINE mode and have fully allocated their ATSC bandwidth. These are the stations that have seen the clock skew issue either intermittantly or chronically based on bandwidth usage.

I realize this is all highly speculative for someone who's never set foot in an affiliate or seen a ROVI encoder, but we now have two separate cases (KEYE and WUSA) where the documented fix proposal from ROVI says, "Relocate the ROVI encoder further "upstream" within the station infrastructure and allocate a specific amount of ATSC bandwidth to it". If my theory is correct that is the same as saying, "stop using INLINE mode and start using DISCREET mode". The response from KEYE was "No way!". The response from WUSA was apparently, "We're working on it."

Doesn't look as it could be for suggested 2) ...

Muxing going on all sources same time - I mean all of them should come as Ethernet packets from different sources or internally making if the muxer has MPEG-2 video/audio engines: [video/audio compressors,] system tables generator (include standard time packets - see whole list of PIDs on any TSReader snapshot), CC, TVGOs, etc

Adding to that major point what Mark outlined to my first suggestion - TVGOS packets is COMING in regular time, eg each 15 seconds. That mean the muxer get those packets on regular ie NORMAL schedule; but a CONTENT of the TVGOS time-stamps is out of normal.

I don't see how it could happen WITHOUT some of sort sync from station's equipment to the [ROVI] black box.

Doesn't look as it could be for suggested 2) ...

Muxing going on all sources same time - I mean all of them should come as Ethernet packets from different sources or internally making if the muxer has MPEG-2 video/audio engines: [video/audio compressors,] system tables generator (include standard time packets - see whole list of PIDs on any TSReader snapshot), CC, TVGOs, etc

Adding to that major point what Mark outlined to my first suggestion - TVGOS packets is COMING in regular time, eg each 15 seconds. That mean the muxer get those packets on regular ie NORMAL schedule; but a CONTENT of the TVGOS time-stamps is out of normal.

I don't see how it could happen WITHOUT some of sort sync from station's equipment to the [ROVI] black box.
I found the last reply I ever got from the KEYE Tech Dir. It sure sounds like he's describing my option #2 (INLINE mode):

--------------------------------------------------------------------
John, Sorry it has taken a while to answer your e-mail. So let me try and explain what is going on. When we installed the ROVI device it was put in after our digital encoder and the last element in the chain before the transmitter. In discussions with them at the time they knew I was doing two channels and CBS requires as part of their affiliate agreement (at that time we were owned by CBS) maximum bandwidth to be used for the video information. I notice you did not get measurements from any other CBS stations in your listing. That said the encoder was hooked up per their instructions and set to carry the information of open packets in the main station digital stream. This was the preferred installation that their system was designed to operate under. Used packets that were randomly available to transmit their data. I also stress that this worked just fine for most users of this data service for several years. Something has changed in their encoding scheme. Their fix is for me to rewire their box and insert the data upstream of our program encoder and program my encoder to give the ROVI a guaranteed amount of my bandwidth. This will require expensive reprogramming of our encoder and rewiring of the plant that I don’t have the time, manpower, or money to do right now. When I ask why the system worked for years and not does not work the way it was installed I get no answer. Quite frankly I do this as a service, receive no compensation and the actual users of the data are limited. I am not going to risk any damage to my video signal or operations to fix something that has changed in their encoding process without out a good explanation of what changed and why. I have encouraged them to find another broadcaster in the market to carry their information but there does not seem to be any takers right now. If they give me a reason for the changes then we might talk but I am sorry they changed how the information is being interpreted we have made no changes from our original installation and operation that is causing this problem. Sorry I cannot be of more help. Dusty GranberryDirector of Broadcast Operations & EngineeringKEYE TV CBS - Telemundo

I need to see block diagrams and to talk to live person ... too much non-technical info what is just blurring picture and prevent from real troubleshooting...

OK, I could add something practical to your analogy.
- the speed is 100 Mbps at least (perhaps they using latest 1Gbps network), mux packet's size is fixed - 188 bytes, network's packet - 1500 bytes so delays are microseconds; also each network packet has TTL - time to live, so the packet cannot traveling or 'stashed' indefinitely (or that long as we speak about minutes).
Most likely (any broadcasting engineers out there ?) the ROVI box has some input port, what accept some cmds from station mux box - like "give me time-stamp" or "flood with your TVGOS data now" and the box is coming from sleep/standby mode for minutes instead of milliseconds. Speculations, speculations ...

Could be and as I tried to say I don't know if the equipment is daisy chained or there is a priority or statistical multiplexer. I would assume that the bandwidth limitation is not the Ethernet connection but the broadcast data rate which I think is around 20mb/sec. You are basically talking about an Ethernet switch as in used on most networks and I have never seen a 7 minute delay. I guess the networks were just not loaded that heavy.

Exactly. At that point in the Austin debug phase, we all concluded that the timestamps are being buffered either internally in the ROVI box or at some MUX downstream of the ROVI box. When I communicated these conclusions to the Tech Director at KEYE, he replied that there is no MUX or any other kind of buffer downstream of the ROVI box in the KEYE infrastructure. Taking him at his word, the only remaining conclusion is that the ROVI box is buffering the timestamps internally when there is insufficient bandwidth available to insert them in real time. This means:

1) The design of the ROVI encoder is flawed. It should never respond to insufficient ATSC bandwidth by inserting skewed timestamps. They should either be inserted real-time or omitted.

2) It is easy to understand how this problem can mysteriously appear/disappear at various affiliates around the country. If their infrastructure is setup similar to KEYE's, the only input variable necessary to trigger/cure the clock skew issue is for their ATSC bandwidth utilization to increase/decrease. That could result from any number of changes that the station might make at any time.

Though the ROVI encoder may be the culprit die to a flawed design, if the CBS stations who suffer the problem are allocating insufficient ATSC bandwidth, couldn't they make a change to correct the situation? Not being a broadcast engr, two questions: 1) Is allocating more bandwidth at the station a major task? And 2) How much change is needed? A fraction of a percent increase? Way more?

Though the ROVI encoder may be the culprit die to a flawed design, if the CBS stations who suffer the problem are allocating insufficient ATSC bandwidth, couldn't they make a change to correct the situation? Not being a broadcast engr, two questions: 1) Is allocating more bandwidth at the station a major task?

I wouldn't think so, but it would mean "robbing Peter to pay Paul" in that they would either have to further compress their primary HD video stream (degrading picture quality slightly) or get rid of a subchannel in order to free up the additional bandwidth. If you read the email I got from KEYE back in 2010, you'll see how eager some affiliates are to do either of those.

And 2) How much change is needed? A fraction of a percent increase? Way more?

Based on a quick survey of null packets (reserve bandwidth) that we did for TVGOS providing affiliates around the country back in 2010, I'd say "very little" is the answer to your question. But bear in mind this solution (in my jargon "retaining INLINE mode" and simply increasing compression of the HD video to free up more bandwidth) is NOT the solution that ROVI is proposing. Probably because it would leave the station susceptible to recurrence of the problem in the future if some other (even slight) new burden is placed on bandwidth in the future. Rather ROVI is proposing to physically rewire the installation of their encoder (in my jargon "changing to DISCREET mode"). Unlike the answer to your #1 above, this sounds like it would be significantly more effort on the part of the station and would also require the same "robbing Peter to pay "Paul" because if they dedicate a certain bandwidth to the ROVI box and they're evidently already running "full out" then it has to come from somewhere. Again, read the response from the KEYE Tech Director to better understand the affiliate perspective.

I would like to add another $0.02 ...

One is imminent and common moment for all troublesome stations (in a case of TVGOS wrong time stamps) id=s low level of reserved bandwidth (null packet stream - PID 1FFFh).

You can't solve the issue by 'relocating' ROVI box.
Other moment of this outage - there is should be specs for it's minimal value - that's must be higher, because it's used usually for main video stream in case of fast actions and changing planes.

I would like to add another $0.02 ...

One is imminent and common moment for all troublesome stations (in a case of TVGOS wrong time stamps) id=s low level of reserved bandwidth (null packet stream - PID 1FFFh).

You can't solve the issue by 'relocating' ROVI box.
Other moment of this outage - there is should be specs for it's minimal value - that's must be higher, because it's used usually for main video stream in case of fast actions and changing planes.

I agree. The "relocating" aspect of the proposed ROVI fix doesn't cure the clock skew. The cure comes from freeing up more bandwidth for the ROVI box to use (at the expense of some other PIDs). All the "relocating" aspect accomplishes is preventing the problem from recurring in the future when some other PID tries to grab more bandwidth.

Then it just changes in muxer'r profile it about PIDs, a few clicks on a computer keyboard ...

I agree. The "relocating" aspect of the proposed ROVI fix doesn't cure the clock skew. The cure comes from freeing up more bandwidth for the ROVI box to use (at the expense of some other PIDs). All the "relocating" aspect accomplishes is preventing the problem from recurring in the future when some other PID tries to grab more bandwidth.

Lots of guessing here as to how it really works but I can think of one case where moving it may work and that is the case where there are idle times interspersed in the stream instead of one big block at the end. IF there are unfilled slots in the stream if a big packet is inserted earlier in the process it has a better chance of finding a slot big enough to fit in before all the slots get stuffed with little things so there is not a big enough slot left. But you are right that only so much will fit and if all the slack is at the end something will have to be pushed off.

My guess is that the TVGOS needs to be sent less often i.e. alternated with something else or only sent when there is free space because as has been discussed it appears that the messages are backing up and we only need the latest one, not all of them.

Adding my new $0.02 to new posted ideas:
- all OTA or DVB packets are small size - 188 bytes.
- TVGOS time-stamp packet (!) it's just one packet (188 bytes) inserting each 15 sec.
- Insertion of the one TVGOS packet happening on time (!) - each 15 sec.
But, the 'time-stamp' inside of the packet (payload) is WRONG(!).

Adding my new $0.02 to new posted ideas:
- all OTA or DVB packets are small size - 188 bytes.
- TVGOS time-stamp packet (!) it's just one packet (188 bytes) inserting each 15 min.
- Insertion of the one TVGOS packet happening on time (!) - each 15 min.
But, the 'time-stamp' inside of the packet (payload) is WRONG(!).

I think you meant they are inserted every 15 seconds, not minutes.

Right.

Adding my new $0.02 to new posted ideas:
- all OTA or DVB packets are small size - 188 bytes.
- TVGOS time-stamp packet (!) it's just one packet (188 bytes) inserting each 15 sec.
- Insertion of the one TVGOS packet happening on time (!) - each 15 sec.
But, the 'time-stamp' inside of the packet (payload) is WRONG(!).

Wouldn't this behavior be consistant with the theory that the ROVI box is internally buffering it's own TVGOS content (guide data & timestamps) and inserting that TVGOS data FIFO into the ATSC stream on a "space available" basis? Wouldn't the result of that be timestamps that grew progressively more and more "stale" during periods of the day when large guide data dumps are pending and then the timestamps would very rapidly "catch up" during periods of the day when there were no large guide data packages to insert?

OH! I see what you're saying... If it were this simple then we would expect there to be large gaps between timstamps during high congestion periods, but we don't; they are delivered steadily every 15s. OK, I give up, I don't know how the encoder works. But we do have written confirmation from KEYE that there was no buffering or MUXing going on downstream of the ROVI box during the Austin clock skew issue, so it has to be an internal buffering issue within the encoder...

Well, I'm circling but I would say:
- muxing happening with all type of data - video/audio/tables and TVGOG info - as INPUTs.

All the sub-streams do processing e.g.MUXING - down stream is one TS (transport stream) MUX what coming to modulator of the station - no more processing with packets.

[If we will see the diagrams, you'll get better picture.]

You guys confusing by yourself, collide 'encoding' and 'muxing' - in this case lets omit encoding processes. It's applicable only to VIDEO and AUDIO sub-streams.

I wouldn't think so, but it would mean "robbing Peter to pay Paul" in that they would either have to further compress their primary HD video stream (degrading picture quality slightly) or get rid of a subchannel in order to free up the additional bandwidth. If you read the email I got from KEYE back in 2010, you'll see how eager some affiliates are to do either of those.



Based on a quick survey of null packets (reserve bandwidth) that we did for TVGOS providing affiliates around the country back in 2010, I'd say "very little" is the answer to your question. But bear in mind this solution (in my jargon "retaining INLINE mode" and simply increasing compression of the HD video to free up more bandwidth) is NOT the solution that ROVI is proposing. Probably because it would leave the station susceptible to recurrence of the problem in the future if some other (even slight) new burden is placed on bandwidth in the future. Rather ROVI is proposing to physically rewire the installation of their encoder (in my jargon "changing to DISCREET mode"). Unlike the answer to your #1 above, this sounds like it would be significantly more effort on the part of the station and would also require the same "robbing Peter to pay "Paul" because if they dedicate a certain bandwidth to the ROVI box and they're evidently already running "full out" then it has to come from somewhere. Again, read the response from the KEYE Tech Director to better understand the affiliate perspective.

I must be missing something. The amount of total bandwidth needed on a daily basis to transmit the ROVI data ought to be absolutely minuscule compared to that used to transmit the actual TV video/audio information itself. Summing the time stamp data with the TVGOS show listing data adds up to what each day, maybe a few thousand bytes? If this ROVI data is as I'm guessing, a tiny, tiny fraction of a percent of the whole, wouldn't making an adjustment in bandwidth allocation to properly accommodate that data have zero effect on picture and sound quality? Not being a broadcast engineer, I'm guessing about this stuff purely based on general communications theory (Shannon' Law, etc.) -- are there other variables at work here?

I must be missing something. The amount of total bandwidth needed on a daily basis to transmit the ROVI data ought to be absolutely minuscule compared to that used to transmit the actual TV video/audio information itself. Summing the time stamp data with the TVGOS show listing data adds up to what each day, maybe a few thousand bytes? If this ROVI data is as I'm guessing, a tiny, tiny fraction of a percent of the whole, wouldn't making an adjustment in bandwidth allocation to properly accommodate that data have zero effect on picture and sound quality? Not being a broadcast engineer, I'm guessing about this stuff purely based on general communications theory (Shannon' Law, etc.) -- are there other variables at work here?While the TVGOS data might be "miniscule" compared to an MPEG stream for one or more video channels, it's hardly in the range of a few thousand bytes a day. In a typical DMA, there are in the vicinity of 600 channels worth of data for 8 days; conservatively estimating 24 shows per day per channel, that's 115000 shows, each of which carries (among other things) descriptive text on the order of 100-200 bytes. Add in zip code mappings and the graphics for logos/ads, and ancillary show information (start time, end time, rating, new-or-rerun) and I'll bet a single pass of all the data adds up to 25+ megabytes. And multiple passes go by each day on some kind of a schedule which I never became acquainted with.

In a typical DMA, there are in the vicinity of 600 channels worth of data for 8 days;
OTA? :confused: