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 465

post #13921 of 18096
Quote:
Originally Posted by Ken H View Post

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?
post #13922 of 18096
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
post #13923 of 18096
Quote:
Originally Posted by J-D-H View Post

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.
post #13924 of 18096
Quote:
Originally Posted by tzdvl View Post

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.
post #13925 of 18096
Quote:
Originally Posted by P Smith View Post

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.
post #13926 of 18096
Quote:
Originally Posted by WillN937 View Post

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
post #13927 of 18096
Quote:
Originally Posted by P Smith View Post

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.
post #13928 of 18096
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.
post #13929 of 18096
Quote:
Originally Posted by mw390 View Post

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.
post #13930 of 18096
Quote:
Originally Posted by mw390 View Post

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
post #13931 of 18096
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
post #13932 of 18096
Quote:
Originally Posted by mw390 View Post

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
post #13933 of 18096
Quote:
Originally Posted by WillN937 View Post

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 ...
post #13934 of 18096
Quote:
Originally Posted by P Smith View Post

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 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
post #13935 of 18096
Quote:
Originally Posted by n0qcu View Post

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.
post #13936 of 18096
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!
post #13937 of 18096
Quote:
Originally Posted by mabuttra View Post

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.
post #13938 of 18096
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 ...
post #13939 of 18096
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."
post #13940 of 18096
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.
post #13941 of 18096
Quote:
Originally Posted by P Smith View Post

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
post #13942 of 18096
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...
post #13943 of 18096
Quote:
Originally Posted by P Smith View Post

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.
post #13944 of 18096
Quote:
Originally Posted by jrpastore View Post

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?
post #13945 of 18096
Quote:
Originally Posted by J-D-H View Post

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.

Quote:
Originally Posted by J-D-H View Post

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.
post #13946 of 18096
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.
post #13947 of 18096
Quote:
Originally Posted by P Smith View Post

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.
post #13948 of 18096
Then it just changes in muxer'r profile it about PIDs, a few clicks on a computer keyboard ...
post #13949 of 18096
Quote:
Originally Posted by jrpastore View Post

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.
post #13950 of 18096
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(!).
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!