or Connect
AVS › AVS Forum › HDTV › HDTV Recorders › The Official AVS Dish DTVPal DVR Topic!
New Posts  All Forums:Forum Nav:

The Official AVS Dish DTVPal DVR Topic! - Page 490

post #14671 of 18096
Quote:
Originally Posted by jrpastore View Post

I disagree. I think the skew is occuring inside the ROVI box in a FIFO buffer and not downstream of the ROVI box within the station infrastructure
[...]

jrpastore, I tend to agree with you about the buffer being in the Rovi encoder, but I really have no idea how the hardware is really set up. Here is my two cents on this subject. I still have one of the log files that you sent to me back when KEYE had the problem, and in my opinion proves that the buffer can hold 9 minutes of data. I have removed all the data except the timestamps around the 'event' that I am referring to.

block length: 0x011, Type: 10/17/2010 12:31:00 GMT
block length: 0x011, Type: 10/17/2010 12:31:15 GMT
block length: 0x011, Type: 10/17/2010 12:31:31 GMT
block length: 0x011, Type: 10/17/2010 12:31:45 GMT
block length: 0x011, Type: 10/17/2010 12:32:00 GMT
block length: 0x011, Type: 10/17/2010 12:32:15 GMT
block length: 0x011, Type: 10/17/2010 12:32:30 GMT
Bad block, filebyte moved: 2008 bytes.
block length: 0x011, Type: 10/17/2010 12:41:45 GMT
block length: 0x011, Type: 10/17/2010 12:42:00 GMT
block length: 0x011, Type: 10/17/2010 12:42:15 GMT
block length: 0x011, Type: 10/17/2010 12:42:30 GMT
block length: 0x011, Type: 10/17/2010 12:42:46 GMT
block length: 0x011, Type: 10/17/2010 12:43:00 GMT
End of data

Unfortunatley this data was taken before P. Smith had his TVGOS logger running so there is no way to tell the actual time that all this occurred. My interpretation is that the buffer (wherever it is, although I believe it is in the Rovi inserter) can only hold 9 minutes of data. I believe the clock data at the top, was skewed -9 minutes, and there was 9 minutes of data backed up in the buffer. This caused the buffer to overflow, and it simply dumped all the data in the buffer and started over. The first timestamp, after the buffer dump, showed a time that was 9 minutes later, and would have been correct.

A year ago Nitewatchman posted 3 log files which I interpreted in this message. Nowhere in those three log files did the timestamps 'skip' forward like the timestamps from your log file. However, his largest time skew was only 7 minutes, which would not be enough (in my opinion) to overflow the buffer. Comparing his log files to yours, the problem at KEYE seemed to be worse than the problem at WHIO.

Mark
post #14672 of 18096
Quote:
Originally Posted by jrpastore View Post

The TTL solution would certainly guarantee that no "stale" timestamp was ever broadcast, however we have no idea how the DTVPal DVR firmware would interpret the resulting TVGOS datastream. Instead of the regular delivery every 15s of a timstamp (sometimes "stale") there would be long periods of several hours where the DVR would receive no timestamp at all. I suspect that as long as it gets a few valid timestamps every 24 hours the DVR would retain its TVGOS "lock" and maintain a pretty accurate clock, but we really don't know what it would do. It's possible the firmware might leave us in an even worse situation with intermimttent timestamps than it does with "stale" timestamps...

I don't believe intermittent timestamps would be an issue, several people have completely lost TVGOS data for a day or two, without any negative effect. There is an issue with the DTVPal if the data is lost for more than 3 days (I believe), but that is just a bug in the DTVPal. Also even if all the timestamps are discarded except for the ones sent out in the evening from 6:30pm to 12:00am. That would still be over 1300 timestamps that the DTVPal would receive every day, and if that isn't enough to keep the DTVPal happy, then nothing can wink.gif.

Mark
post #14673 of 18096
Quote:
Originally Posted by jrpastore View Post

I disagree. I think the skew is occuring inside the ROVI box in a FIFO buffer and not downstream of the ROVI box within the station infrastructure. Here are my reasons:
1) KEYE Tech Director told me explicitly that there is no MUX or buffer of any kind downstream of the ROVI box. He said that ROVI provided two installation options for their encoder: A) UPSTREAM of the station MUX with a dedicated bandwidth allocation assigned to the encoder within the MUX. B) DOWNSTREAM of the station MUX with no need to pre-assign any ATSC bandwidth to the encoder. Not surprisingly KEYE and apparently many other stations chose the DOWNSTREAM installation option because it requires much less effort on their part and does not impose any burden on their ATSC bandwidth.
2) The published FIX from ROVI is to RELOCATE their encoder from the DOWNSTREAM position to the UPSTREAM position within the station infrastructure and assign the required bandwidth to the encoder within the station MUX. Essentially they are admitting that their original instructions to the stations were erroneous. There really is only one robust installation option for their encoder, not two, as originally advised. If the clock skew observed at KEYE and other stations was occuring within the station infrastructure downstream of the encoder as you suggest, then physically relocating the encoder to a position further upstream would be meaningless.
3) As WillN937 pointed out, we never see skew of greater than 7 minutes in any broadcast market. If the skew is occuring downstream of the encoder in some station-owned piece of hardware, I would expect to see more variation in the maximum magnitude of skew between stations. Unless every station uses the exact same model of ATSC MUX or all models of ATSC MUX on the market have the exact same buffer capacity, which seems very unlikely.
4) The fact that the stream logs from Austin show timestamps present every 15 seconds regardless of whether they are" fresh" (real-time) or "stale" (skewed) means that there is some kind of dual-mode behavior going on at the point of buffering (wherever it is). If a downstream MUX or other station-owned hardware was doing the buffering, how could it reliably ensure that a timestamp gets inserted at perfect 15s intervals and yet never allow the max skew to get above 7 mins?
As I said, all we have is a working THEORY as to what goes within the station infrastructure to generate the skew, but I think the idea that the buffering is occuring internal to the ROVI encoder is the simplest explanation that would explain ALL the observations made to date. And that is how the scientific method works right? The simplest theory is assumed to be correct until either some new data contradicts it, or somebody comes up with an even simpler explanation that still explains all the observations...
Thanks for the good write up. We discussed the issue a few times and it's nice to see you collect that scattered info in one good post.
[Perhaps my conclusions are just a result of fragmentary of the info and my memory selectivity]

I would tend to agree with you after the pictured configs. But finally I would come with network sniffer and sitting at station network room do some tracing and measuring.
It's understandably no such station engineer have time and desire get to the root of the problem when the 'black box' [ROVI equipment] is not allow to get inside.
Seems to me we will have no answers at all before some 'crazy' station engineer will participate here ...
post #14674 of 18096
Quote:
Originally Posted by P Smith View Post

Thanks for the good write up. We discussed the issue a few times and it's nice to see you collect that scattered info in one good post.
[Perhaps my conclusions are just a result of fragmentary of the info and my memory selectivity]
I would tend to agree with you after the pictured configs. But finally I would come with network sniffer and sitting at station network room do some tracing and measuring.
It's understandably no such station engineer have time and desire get to the root of the problem when the 'black box' [ROVI equipment] is not allow to get inside.
Seems to me we will have no answers at all before some 'crazy' station engineer will participate here ...

Everyone has a theory. I tend to agree with you because I interpret the ROVI instructions (#2 in jrpastore's post) to mean that they thought that their box could queue the data until it found an empty slot to insert it and the reality is that by the time it gets to them there are no slots that will hold all the TVGOS data (more than the few bytes needed for just time) so they just wait. If we make the assumption that the station engineers are not willing to carve out bandwidth for TVGOS because they are lazy, don't know how or most likely just don't want to dedicate the bandwidth. I don't believe there are enough OTA TVGOS users with torches outside of stations to really concern the stations since most people still have cable that includes an EPG and not every device is TVGOS equipped. Therefore, assuming you are correct, the only way the problem will be fixed is if ROVI changes their software to do something like one of the following because the stations are not going to do anything:
  • Don't queue time (don't send stale time, e.g. update the packet just before it is inserted).
  • Don't queue the packets. If you can't insert a packet, just discard it.
  • Send a fresh time packet even if there is not enough space to send all of the TVGOS data.
  • I don't know about "real" TVGOS devices but the PAL remembers the TVGOS data and the clock will run a long time without updates before it gets off enough to matter so updates every 15 seconds is not really necessary but the data needs to be good when it is sent.

Anyhow that is what I think.
post #14675 of 18096
Quote:
Originally Posted by mabuttra View Post

jrpastore, I tend to agree with you about the buffer being in the Rovi encoder, but I really have no idea how the hardware is really set up. Here is my two cents on this subject. I still have one of the log files that you sent to me back when KEYE had the problem, and in my opinion proves that the buffer can hold 9 minutes of data. I have removed all the data except the timestamps around the 'event' that I am referring to.
block length: 0x011, Type: 10/17/2010 12:31:00 GMT
block length: 0x011, Type: 10/17/2010 12:31:15 GMT
block length: 0x011, Type: 10/17/2010 12:31:31 GMT
block length: 0x011, Type: 10/17/2010 12:31:45 GMT
block length: 0x011, Type: 10/17/2010 12:32:00 GMT
block length: 0x011, Type: 10/17/2010 12:32:15 GMT
block length: 0x011, Type: 10/17/2010 12:32:30 GMT
Bad block, filebyte moved: 2008 bytes.
block length: 0x011, Type: 10/17/2010 12:41:45 GMT
block length: 0x011, Type: 10/17/2010 12:42:00 GMT
block length: 0x011, Type: 10/17/2010 12:42:15 GMT
block length: 0x011, Type: 10/17/2010 12:42:30 GMT
block length: 0x011, Type: 10/17/2010 12:42:46 GMT
block length: 0x011, Type: 10/17/2010 12:43:00 GMT
End of data
Unfortunatley this data was taken before P. Smith had his TVGOS logger running so there is no way to tell the actual time that all this occurred. My interpretation is that the buffer (wherever it is, although I believe it is in the Rovi inserter) can only hold 9 minutes of data. I believe the clock data at the top, was skewed -9 minutes, and there was 9 minutes of data backed up in the buffer. This caused the buffer to overflow, and it simply dumped all the data in the buffer and started over. The first timestamp, after the buffer dump, showed a time that was 9 minutes later, and would have been correct.
A year ago Nitewatchman posted 3 log files which I interpreted in this message. Nowhere in those three log files did the timestamps 'skip' forward like the timestamps from your log file. However, his largest time skew was only 7 minutes, which would not be enough (in my opinion) to overflow the buffer. Comparing his log files to yours, the problem at KEYE seemed to be worse than the problem at WHIO.
Mark

That's right, I had forgotten about the detailed workup you were able to do on the WHIO data. So sounds like 7min max skew that we typically see is more a function of the 45 min length of the guide data downloads, and not a restriction imposed by the size of the FIFO buffer. The 9 min skew (even a single instance of it) proves that much. Whehther in fact the FIFO buffer size is limited to 9 min of data and was the reason for the data dump (bad block) and subsequent skew recovery episode that you found is still an open question. It's just the mechanics of the buffering that have me puzzled. It seems like the simple scenario of a buffer that occasionally starts to fill in response to a bandwidth shortage would result in gaps where no timestamps were inserted, but we don't see that. We see a timestamp every 15s regardless of whether there is clock skew or not...
post #14676 of 18096
Quote:
Originally Posted by WillN937 View Post

Everyone has a theory. I tend to agree with you because I interpret the ROVI instructions (#2 in jrpastore's post) to mean that they thought that their box could queue the data until it found an empty slot to insert it and the reality is that by the time it gets to them there are no slots that will hold all the TVGOS data (more than the few bytes needed for just time) so they just wait. If we make the assumption that the station engineers are not willing to carve out bandwidth for TVGOS because they are lazy, don't know how or most likely just don't want to dedicate the bandwidth. I don't believe there are enough OTA TVGOS users with torches outside of stations to really concern the stations since most people still have cable that includes an EPG and not every device is TVGOS equipped. Therefore, assuming you are correct, the only way the problem will be fixed is if ROVI changes their software to do something like one of the following because the stations are not going to do anything:
  • Don't queue time (don't send stale time, e.g. update the packet just before it is inserted).
  • Don't queue the packets. If you can't insert a packet, just discard it.
  • Send a fresh time packet even if there is not enough space to send all of the TVGOS data.
  • I don't know about "real" TVGOS devices but the PAL remembers the TVGOS data and the clock will run a long time without updates before it gets off enough to matter so updates every 15 seconds is not really necessary but the data needs to be good when it is sent.
Anyhow that is what I think.

Yep, the only robust fix to his issue is an update to the ROVI encoder, possibly just new firmware, but maybe a hardware change would be required as well. Either way it's engineering $ that ROVI would have to spend. I think we'll see peace in the middle east and bipartisan cooperation on capitol hill before we see ROVI spend another nickel worrying about a tiny community of OTA DVR users from whom they receive no revenue. Their first response to us on this issue back in 2010, was essentially to "go pound sand". The only reaon they eventually felt compelled to spend at least a little engineering money looking into the problem is because at least one station manager championed our cause and demanded that they do something to fix the problem. ROVI has a financial interest in keeping the station managers satisfied, they have absolutely no financial interest in keeping DTVPal users satisfied. You know what they say, money makes the workd go round...
post #14677 of 18096
If it's only one force to do their job... I' would be ashamed to be an EE nor SW developer with the ROVI team.

{I'll tell you ... on my last job I had heated public technical discussion with HW Dept head from a base of real passion of my work and I'm proud of it, regardless sudden outcome. It's started from customer's side _possible_ issue and must be handled by SW dept easy, but ...}
Edited by P Smith - 9/30/12 at 8:34pm
post #14678 of 18096
Quote:
Originally Posted by jrpastore View Post

[...]
It's just the mechanics of the buffering that have me puzzled. It seems like the simple scenario of a buffer that occasionally starts to fill in response to a bandwidth shortage would result in gaps where no timestamps were inserted, but we don't see that. We see a timestamp every 15s regardless of whether there is clock skew or not...

All of the data is put into the buffer, the data is just slow going out of the buffer. Think of the buffer as being the upper globe of an hour glass. The hole that the sand goes through is the bandwidth limit that is being imposed on the data. The data enters at the top of the hour glass passes (hopefully) freely through the upper globe, through the hole, and right on out the bottom of the hourglass to the station transmitter. As long as the data flow is low (like in the evening), data passes freely through the hourglass. When the data flow increases it can't all fit through the hole in the hourglass, so it starts backing up into the upper globe. This continues until the next period of low bandwidth data, at which point the buffer can empty out much faster than the data coming in. As long as the buffer didn't completely fill, all the data will eventually get sent out.

When there is clock skew, the inserter doesn't actually send 1 timestamp every 15 seconds. In 45 minutes, at the rate of 4 timestamps per minute, the inserter should send out 180 timestamps. If after 45 minutes there is 7 minutes of clock skew, it means that the inserter was only able to insert 152 timestamps (at the 45 minute mark it is only receiving data for the 38th minute, so that is 38 minutes * 4 timestamps per minute = 152). The other 22 timestamps are still backed up in the encoder's buffer. At the rate of 152 timestamps in 45 minutes it comes out to 3.3778 timestamps per minute, or 1 timestamp every 17.76 seconds. So during times of clock skew, each timestamp is delayed by more than 2 seconds. If you only look at the TVGOS data, you can't tell there is anything wrong, like you said, the timestamps appear to be coming in every 15 seconds. The only way to see the skewed timestamps is to use P. Smith's TSReader logger which shows the difference between the computer clock, and the TVGOS timestamps.

Here is part of one of those WHIO logs that shows only the timestamps:
09/29/11 10:14:01 TVG SCN= 1 TS: Thu Sep 29 10:13:00 2011 [-61 s]
09/29/11 10:14:19 TVG SCN=16 TS: Thu Sep 29 10:13:15 2011 [-64 s]
09/29/11 10:14:36 TVG SCN=30 TS: Thu Sep 29 10:13:30 2011 [-66 s]
09/29/11 10:14:55 TVG SCN=13 TS: Thu Sep 29 10:13:46 2011 [-69 s]
09/29/11 10:15:12 TVG SCN=27 TS: Thu Sep 29 10:14:01 2011 [-71 s]
09/29/11 10:15:29 TVG SCN= 9 TS: Thu Sep 29 10:14:16 2011 [-73 s]
09/29/11 10:15:47 TVG SCN=23 TS: Thu Sep 29 10:14:31 2011 [-76 s]
09/29/11 10:16:04 TVG SCN= 5 TS: Thu Sep 29 10:14:46 2011 [-78 s]
09/29/11 10:16:22 TVG SCN=19 TS: Thu Sep 29 10:15:01 2011 [-81 s]
09/29/11 10:16:38 TVG SCN= 3 TS: Thu Sep 29 10:15:15 2011 [-83 s]
09/29/11 10:16:57 TVG SCN=21 TS: Thu Sep 29 10:15:31 2011 [-86 s]

See how the clock skew with each timestamp is two to three seconds worse than the last one. In each minute there are 10 more seconds of clock skew being added.

Mark
post #14679 of 18096
If support buffering idea, then we need to bring other point - ROVI box must has an input control line(s) to wait for a signal to send packets or wait ...

I'm really want to see all the diagrams; we are shooting into dark, just building theories when it's all determined, the relation between station's equipment and the black box. At least we must have all lines in/out of the ROVI device.
post #14680 of 18096
P. Smith,

I think this whole ROVI box discussion is way off topic. Seeing as you pick on my posts I am taking the opportunity to remind you of YOUR rules. However I really don't object to you guys discussing this and don't want the moderator to step in.
post #14681 of 18096
You're right - no questions.




In my defense: I did propose initially to get open a new dedicated thread, but it looks like only owners of TR50/DTVpal DVR are interesting in the aspect of functioning ROVI equipment particularly and getting TVGOS data/time from such in general.
post #14682 of 18096
Quote:
Originally Posted by mabuttra View Post

All of the data is put into the buffer, the data is just slow going out of the buffer. Think of the buffer as being the upper globe of an hour glass. The hole that the sand goes through is the bandwidth limit that is being imposed on the data. The data enters at the top of the hour glass passes (hopefully) freely through the upper globe, through the hole, and right on out the bottom of the hourglass to the station transmitter. As long as the data flow is low (like in the evening), data passes freely through the hourglass. When the data flow increases it can't all fit through the hole in the hourglass, so it starts backing up into the upper globe. This continues until the next period of low bandwidth data, at which point the buffer can empty out much faster than the data coming in. As long as the buffer didn't completely fill, all the data will eventually get sent out.
When there is clock skew, the inserter doesn't actually send 1 timestamp every 15 seconds. In 45 minutes, at the rate of 4 timestamps per minute, the inserter should send out 180 timestamps. If after 45 minutes there is 7 minutes of clock skew, it means that the inserter was only able to insert 152 timestamps (at the 45 minute mark it is only receiving data for the 38th minute, so that is 38 minutes * 4 timestamps per minute = 152). The other 22 timestamps are still backed up in the encoder's buffer. At the rate of 152 timestamps in 45 minutes it comes out to 3.3778 timestamps per minute, or 1 timestamp every 17.76 seconds. So during times of clock skew, each timestamp is delayed by more than 2 seconds. If you only look at the TVGOS data, you can't tell there is anything wrong, like you said, the timestamps appear to be coming in every 15 seconds. The only way to see the skewed timestamps is to use P. Smith's TSReader logger which shows the difference between the computer clock, and the TVGOS timestamps.
Here is part of one of those WHIO logs that shows only the timestamps:
09/29/11 10:14:01 TVG SCN= 1 TS: Thu Sep 29 10:13:00 2011 [-61 s]
09/29/11 10:14:19 TVG SCN=16 TS: Thu Sep 29 10:13:15 2011 [-64 s]
09/29/11 10:14:36 TVG SCN=30 TS: Thu Sep 29 10:13:30 2011 [-66 s]
09/29/11 10:14:55 TVG SCN=13 TS: Thu Sep 29 10:13:46 2011 [-69 s]
09/29/11 10:15:12 TVG SCN=27 TS: Thu Sep 29 10:14:01 2011 [-71 s]
09/29/11 10:15:29 TVG SCN= 9 TS: Thu Sep 29 10:14:16 2011 [-73 s]
09/29/11 10:15:47 TVG SCN=23 TS: Thu Sep 29 10:14:31 2011 [-76 s]
09/29/11 10:16:04 TVG SCN= 5 TS: Thu Sep 29 10:14:46 2011 [-78 s]
09/29/11 10:16:22 TVG SCN=19 TS: Thu Sep 29 10:15:01 2011 [-81 s]
09/29/11 10:16:38 TVG SCN= 3 TS: Thu Sep 29 10:15:15 2011 [-83 s]
09/29/11 10:16:57 TVG SCN=21 TS: Thu Sep 29 10:15:31 2011 [-86 s]
See how the clock skew with each timestamp is two to three seconds worse than the last one. In each minute there are 10 more seconds of clock skew being added.
Mark

Thanks for taking the time to spell all that out so clearly Mark. I remember undertanding your original explanation when you posted it last year. Unfortunately, I'm like P Smith, I can't keep all the various datapoints in my head at once. Got it now!
post #14683 of 18096
Quote:
Originally Posted by jrpastore View Post

.... ROVI has a financial interest in keeping the station managers satisfied, they have absolutely no financial interest in keeping DTVPal users satisfied. You know what they say, money makes the workd go round...
I have been lead to believe that this affects more TVGOS OTA users than just the PAL DVR. I have seen Sony users complaining of the same problem.
post #14684 of 18096
Rovi Response to my email about the 7 minute TVGOS clock delay:

Hi Len,

Good news that your clock is back to the correct time. The clock on our equipment is
correct. It is during some hi data traffic times that our clock packets which do not get
priority in the data stream get backed up. This is what causes the clock on your DVR to
appear slow.

We have a solution recommended to the station that involves physically moving our
equipment further up the data stream. Station engineers have said they may or may not
be able to do this at some time in the future.

Regards,

CE Technical Support
Rovi
post #14685 of 18096
The point from ROVI supporting the my clause of buffering by station's equipment. Duh. wink.gif
post #14686 of 18096
Quote:
Originally Posted by LenL View Post

Rovi Response to my email about the 7 minute TVGOS clock delay:
Hi Len,
Good news that your clock is back to the correct time. The clock on our equipment is
correct. It is during some hi data traffic times that our clock packets which do not get
priority in the data stream get backed up. This is what causes the clock on your DVR to
appear slow.
We have a solution recommended to the station that involves physically moving our
equipment further up the data stream. Station engineers have said they may or may not
be able to do this at some time in the future.
Regards,
CE Technical Support
Rovi
Got the same response from ROVI several years ago. So far WHIO has done nothing.
post #14687 of 18096
If you want check what time your station provide thru PSIP use Menu-3-2-6 and PgUp/PgDn - check the screen with constantly updating time and other info from PSIP packets.
post #14688 of 18096
Quote:
Originally Posted by P Smith View Post

If you want check what time your station provide thru PSIP use Menu-3-2-6 and PgUp/PgDn - check the screen with constantly updating time and other info from PSIP packets.
How do you tell which station is which?
post #14689 of 18096
Quote:
Originally Posted by P Smith View Post

If you want check what time your station provide thru PSIP use Menu-3-2-6 and PgUp/PgDn - check the screen with constantly updating time and other info from PSIP packets.

I tried this, but the only numbers that were correct were the year. eek.gif I've alway had good TVGOS data so I never noticed an issue....I guess. I checked all the 'idents' (pg/dn multiple times) they were all way off. I didn't change the channel; suppose I might have one channel giving bad data?...I'll have to check when I get back there.
Edited by ccrider2 - 10/4/12 at 2:50pm
post #14690 of 18096
Quote:
Originally Posted by ccrider2 View Post

I tried this, but the only numbers that were correct were the year. eek.gif I've alway had good TVGOS data so I never noticed an isse....I guess. I checked all the 'idents' (pg/dn multiple times) they were all way off. I didn't change the channel; suppose I might have one channel giving bad data?...I'll have to check when I get back there.

Check it again. The time is GMT not local time (4 hours ahead for Eastern time, and 5 hours ahead for Central time). The dates are in day/month/year format instead of the usual month/day/year format (so today shows as 4/10/2012).

Mark
post #14691 of 18096
Quote:
Originally Posted by Chuck44 View Post

How do you tell which station is which?
Easy smile.gif
Get TSID and lookup at www.rabbitear.info
post #14692 of 18096
Quote:
Originally Posted by mabuttra View Post

Check it again. The time is GMT not local time (4 hours ahead for Eastern time, and 5 hours ahead for Central time). The dates are in day/month/year format instead of the usual month/day/year format (so today shows as 4/10/2012).
Mark

I figured out the date.....GMT explains the rest.

Thanks for clearing that up.
post #14693 of 18096
NCIS Broacast with SAP ON Tuesday.

I recorded NCIS and NCIS LA back to back on Tuesday. When I viewed them last nite, NCIS had SAP with a narrative of the action when there wasn't any dialog. I tried everthing to shut this off on the recording but nothing worked. The next show that followed right after NCIS LA there was no SAP.

This is the second time in the past year that NCIS was recorded and I viewed it and SAP was present.

Any ideas on why and what can be done to stop on the PALDVR. I tried hitting the SAP button on the remote but that did nothing.
post #14694 of 18096
Quote:
Originally Posted by LenL View Post

NCIS Broacast with SAP ON Tuesday.
I recorded NCIS and NCIS LA back to back on Tuesday. When I viewed them last nite, NCIS had SAP with a narrative of the action when there wasn't any dialog. I tried everthing to shut this off on the recording but nothing worked. The next show that followed right after NCIS LA there was no SAP.
This is the second time in the past year that NCIS was recorded and I viewed it and SAP was present.
Any ideas on why and what can be done to stop on the PALDVR. I tried hitting the SAP button on the remote but that did nothing.
Must have been a local thing. I watched the same shows through my DVR and did not have the problem.
post #14695 of 18096
Quote:
Originally Posted by WillN937 View Post

Got the same response from ROVI several years ago. So far WHIO has done nothing.

You are correct, sir. I decided to program the correct Dayton zip code into one of my two Pal DVRs just to check to see if the time was still off with WHIO. As of this morning, it's 3 minutes slow. The other DVR with a Cincinnati zip code has been spot-on. This has been going on for what--the better part of a year??? Pathetic!
post #14696 of 18096
Quote:
Originally Posted by LenL View Post

I tried everthing to shut this off on the recording but nothing worked.

I guess that means you pressed the SAP button and the word "ENGLISH" appeared in the program information and before the info cleared you pressed SAP again. Did it appear to cycle through alternate audio tracks. Does your CBS station even have alternate audio tracks?

I recorded a PBS program that did not have a narration track only music and sound effects. (Took 10 minutes to figure that one out.) Turns out they were working 5.1 encoder that day and I didn't get the center channel.
post #14697 of 18096
Quote:
Originally Posted by LenL View Post

NCIS Broacast with SAP ON Tuesday.
I recorded NCIS and NCIS LA back to back on Tuesday. When I viewed them last nite, NCIS had SAP with a narrative of the action when there wasn't any dialog. I tried everthing to shut this off on the recording but nothing worked. The next show that followed right after NCIS LA there was no SAP.
This is the second time in the past year that NCIS was recorded and I viewed it and SAP was present.
Any ideas on why and what can be done to stop on the PALDVR. I tried hitting the SAP button on the remote but that did nothing.

There is a similar quirk I've experienced with my DTVPal CECB (not DVR). When watching the local PBS channel with the CECB, it sometimes plays the audio designed for the visually impaired. That is between all dialogue, a soft narrator's voice describes the scene or character's actions. When going into the setup menu and choosing either the main vs. alternate audio programming, there was no way to shut off the narration. When checking on TVs in other rooms, the narration was absent.

In regards to the DTVPAl DVR (I have 5 of them), I've had a few mysterious audio occurrences over the past year or so, and never found out why they occurred.

One time I recorded a program with the DTVPal DVR, and the audio track was entirely in Spanish. Checking back on the SAP settings there was nothing to indicate that anything had changed. Other people I talked to that watched the program live said it was in English on their sets.

Another time I was recording a prime time movie at the same time I was watching it (one of the Jesse Stone dramas). I noticed right off that the program audio track sounded strange. All the background (surround?) sounds were quite loud, and there was no music track at all. After a few minutes of the introductory credits rolling and the characters finally appeared on screen I realized there were no voices present. (This is very similar to what Pete-N2 just posted, but not quite the same.) I thought this was strange that the broadcasters could have made such a mistake, and that they must be getting a lot of calls complaining, especially with such a hyped up show. When commercials came on, they appeared normal. When the commercials ended and the program came back on, there was still no main audio information. I checked the TV and DVR settings to see if SAP had been selected, and both indicated that English was the only choice available. Pressing the SAP buttons on the DVR and TV made no difference. I then went into another room and turned on the TV to find the audio track was normal in that room. Both TVs were being fed by DTVPal DVRs, both with identical settings and the same (F208) software. I never did find out why the one box played and recorded only the background audio and not the main track. I asked here, but was told by an "expert" here that what I described was impossible, as he said the additional background audio is not broadcast separate from the main program. But in actuality, the main audio track was absent on one DVR while simultaneously present on another.

A third time was similar to the first instance. I was watching an old rerun of "Cops" on the local "MyNetworkTV" channel and the audio was again in Spanish. I checked the SAP, and English was the only choice available. I turned on a 2nd DTVPal DVR to find it in English on that one. I went back to the first one, turned it off and back on, still in Spanish. I then did a reboot (Hold power button down until it reboots) and when it came back on the audio was then in English, as it should have been.

So there is a quirk somewhere, I'm not the only one to have reported it here in this thread in the past, but it is apparently a rare occurrence. As such, there is likely no cure, it must be an incompatibility somewhere between the broadcast signal and the DTVPal DVR, and only appears as an occasional glitch.
post #14698 of 18096
Quote:
Originally Posted by Paul210 View Post

You are correct, sir. I decided to program the correct Dayton zip code into one of my two Pal DVRs just to check to see if the time was still off with WHIO. As of this morning, it's 3 minutes slow. The other DVR with a Cincinnati zip code has been spot-on. This has been going on for what--the better part of a year??? Pathetic!

OK, maybe I exagerated a bit. The last thing I heard from ROVI was in May.

Hello,

The update we have is that station engineers at WHIO have been unresponsive to our request. Our Broadcast Engineer will give them another try, but does not expect much.

Regards,

CE Tech Support
Rovi
post #14699 of 18096
For what it's worth, my PBS station has two audio tracks both labeled "ENGLISH." The DVR records only one titled "UNKNOWN." My NBC station has two audio tracks labeled "ENGLISH" and "SPANISH. The DVR records both titled "ENGLISH" and "UNKNOWN." My FOX station also has two audio tracks labeled "ENGLISH" and "SPANISH. The DVR records both titled "ENGLISH" and (you guessed it) "SPANISH"
post #14700 of 18096
Quote:
Originally Posted by LenL View Post

NCIS Broacast with SAP ON Tuesday.
I recorded NCIS and NCIS LA back to back on Tuesday. When I viewed them last nite, NCIS had SAP with a narrative of the action when there wasn't any dialog. I tried everthing to shut this off on the recording but nothing worked. The next show that followed right after NCIS LA there was no SAP.
This is the second time in the past year that NCIS was recorded and I viewed it and SAP was present.
Any ideas on why and what can be done to stop on the PALDVR. I tried hitting the SAP button on the remote but that did nothing.

I've had a similar situation occur with my DTVPal. For me, the narrative happened when I recorded the season premire of Criminal Minds (also have had this occur in an earlier episode of Criminal Minds). Along with the narrative, I've had my DTVPal occasionally record a program in Spanish thought I didn't choose Spanish.

The occurances happens enough over the past year that recently I finally decided to throw in the towel and get a different brand (Digital Stream) DVR. The Digital Stream lacks a lot of the convenient features of the DTVPal but the unfixable bugs of the DTVPal is just too much for me.

As for now, I still have my DTVPal as a backup machine in storage should the Digital Stream go kaput.
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: HDTV Recorders
AVS › AVS Forum › HDTV › HDTV Recorders › The Official AVS Dish DTVPal DVR Topic!