510 Buffer Question

Smith said:
If they can't add in PVR501+ firmware one simple check for LBA48 flag and accept disks more then 137 GB. I wouldn't talk about more complicated multi channels buffer. :(
It's not that they can't, it's that they won't. If you want a bigger box, they're happy to sell you one. :smug
 
SimpleSimon said:
Dunno about him, but "I" do - 30 years worth. Beta tested the 8086 in a real-time, 100% reliability required, system while at Siemens. Thought Unix was cool 25 years ago (shame it hasn't improved since then). Implemented interactive support (like these forums) almost 20 years ago.

So, having built my soapbox, and remembering that I have a guesstimate as to why it doesn't work that way (but probably should)...

Well I don't have 30 yrs, but do have 17 software development years of experience in process control, network, and storage system management systems.. ;) Mainly in usability. The main point I was trying to make is that is hard to determine the difficulty of a feature without knowing the architecture and limitations of the architecture.


SimpleSimon said:
The buffer is already on hard disk. Other than that, you're right, there's some issues there.

Are you sure about this with the 508? I was not sure if the buffer was in memory or on the drive. Interesting to know. Never thought about the memory requirement.

SimpleSimon said:
Yes, they are separate, but no stitching required. The boundary is just forced to a P-frame or whatever it's called - the 'full image' frame that is sent 'every now and then'. You can see them - it's what causes the 'jerkiness' when messing around in single-frame mode going backwards and such. the decoder has to have a starting point. :) Besides, on a 921, it takes forever to change channels, so plenty of black space to play with.
Understood but there would still be some stiching required on the MPEG2 streams or they would need some type of stream managment so the box knows how to transverse from one stream to the next. Not saying it is not possible. Just saying it is a more difficult algorithm. Then again, I have not played around with MPEG2 algorithms so this might be trivial. My only experience here is home video editing. ;)

SimpleSimon said:
No, it could be done - with the caveat that you couldn't hit 'record' unless you were on the 'current' show. And when all is said and done, that might be the overriding issue - user confusion when they can't do stuff like that. :cool:

I think we agreed here, that yes it can be done. My personal opinion is that the designed was right given the usability complications that doing it the other way would present. That is my gut feel not given it the full analysis it deserves.. My main point was that I run into a lot of people that think software changes that look trival on the outside are trivial on the inside. This is not the case and is the exception more than the rule. ;) That has been my experience.

Well my main point was that this works as designed and it is not as dumb as some people may think it is. Just because a feature does not work they way one person may expect it to does not mean it points to bad software development. It just means that the feature had a different intention and the developers saw it being used in a different way. Having used the 508 for a year now, having it work the other way I feel would be very confusing. Yes there are times when you switch channels and wish you could get back the buffer, but those I have found are few from my experience. I am but one use case though.
 
WeeJavaDude said:
... The main point I was trying to make is that is hard to determine the difficulty of a feature without knowing the architecture and limitations of the architecture.
True, but sometimes certain things can be inferred. For example, with the 921 (I don't remember how my 501 acts), I can infer that the show information is stored 'closer' to the video stream than the event directory. Why? Because when 'padding' the event, the preceding/trailing show information is retained. Also, manual events that span shows have the correct info - regardless of the number of shows in the event.
WeeJavaDude said:
Are you sure about this with the 508? I was not sure if the buffer was in memory or on the drive. Interesting to know. Never thought about the memory requirement.
My rationale there is simple. The box doesn't have 2GB of RAM to hold an hours worth of video. :)
WeeJavaDude said:
Understood but there would still be some stiching required on the MPEG2 streams or they would need some type of stream managment so the box knows how to transverse from one stream to the next. Not saying it is not possible. Just saying it is a more difficult algorithm. Then again, I have not played around with MPEG2 algorithms so this might be trivial. My only experience here is home video editing. ;)
Maybe our definitions of stitching are different. I believe that you can take 2 MPEG-2 streams and butt them together quite easily - as long as the 2nd stream starts on a P-frame (I think that's the right term).
WeeJavaDude said:
I think we agreed here, that yes it can be done. My personal opinion is that the design was right given the usability complications that doing it the other way would present. That is my gut feel not given it the full analysis it deserves.. My main point was that I run into a lot of people that think software changes that look trival on the outside are trivial on the inside. This is not the case and is the exception more than the rule. ;) That has been my experience.
Yeah - for sure - and sometimes things that seem trivial are horribly complex and vice versa. I've had a few bosses like that.
WeeJavaDude said:
Well my main point was that this works as designed and it is not as dumb as some people may think it is. Just because a feature does not work they way one person may expect it to does not mean it points to bad software development. It just means that the feature had a different intention and the developers saw it being used in a different way. Having used the 508 for a year now, having it work the other way I feel would be very confusing. Yes there are times when you switch channels and wish you could get back the buffer, but those I have found are few from my experience. I am but one use case though.
We agree there - except that I've seen too many things in Dish DVRs that indicate the typically lousy state of the software. Not that that's limited to Dish - it's all over the industry - quality just isn't a priority in most shops any more. :no
 
rbowles said:
I believe the 510 has a 2 hour buffer, not 1 hour. The 501 and 508 have 1 hour buffers.
And now that I think about it, the 522 would have 2 one hour (or longer) buffers. Either way, that would double the RAM requirement, to something above what a 32-bit CPU can handle. So, I believe we've now really confirmed the buffer is on disk. :)

Aside, this is an example of how architecture inferences and the subsequent design analysis can be done. :yes
 
Smith said:
Which one ? May be you want to make the proposal ? :cool:
Not sure what you mean, but the 921 has a 250GB HDD. Don't knopw of any others. Of course, if you don't care about HD, you could probably just go with multiple 5xx receivers for less money than that.
 
WeeJavaDude said:
If I had a nickel for every time someone made a comment about how it should be easy to implement having not actually implemented production level code, I would be a rich man. Gary do you have experience doing this?

.


I have plenty of experience making comments like that.
 
WeeJavaDude said:
This is actually different because DVDR is not integrated with the Tuner and only records the stream coming in just like a VCR can do when set to an external input. That is why it records what it sees. This is different than and integrated PVR. I would assume that a standard TIVO would work the same way.

As for skipping commercials. This is more a policital issues with the networks than implementation issues. At one time they had VCRs that would automatically skip commercials but they were quickly removed from the market. The 50x does have a 30 second skip that works great for skipping commercials, but having the ability to skip them and not record them is something I don't expect and DVRs to do in the near future. Just way to hot of a political issue.

Huh?

I don't see how any of this even begins to answer the question, which was essentially, "if DVDR's can pause-record and change the source during recordings, why can't PVR's pause-record or change channels without dumping the buffer?". I already proved that changing the input is technically possible without mucking up the recording by using a cable STB.

Disregard IRD/PVR's for the moment, as that just complicates the question needlessly. Both a PVR and a DVDR have an MPEG encoder and a decoder, and a medium to record on, and both use the same techniques to record and play back. They likely even use the same chipsets in many cases. They are technical siblings, not identical twins, but nearly fraternal. Only the OS seems to be what keeps PVR's from having this capability.

Also, disregard any political motivations for not allowing pause. If that were a consideration, they wouldn't allow skipping commercials either, and Charlie Ergen would not be able to be quoted over and over again as saying that the ability to skip commercials is his favorite feature of PVR's. It's a purely technical issue, which is why I posed a technical question.
 
TyroneShoes said:
Huh?

I don't see how any of this even begins to answer the question, which was essentially, "if DVDR's can pause-record and change the source during recordings, why can't PVR's pause-record or change channels without dumping the buffer?". I already proved that changing the input is technically possible without mucking up the recording by using a cable STB.

Disregard IRD/PVR's for the moment, as that just complicates the question needlessly. Both a PVR and a DVDR have an MPEG encoder and a decoder, and a medium to record on, and both use the same techniques to record and play back. They likely even use the same chipsets in many cases. They are technical siblings, not identical twins, but nearly fraternal. Only the OS seems to be what keeps PVR's from having this capability.

Also, disregard any political motivations for not allowing pause. If that were a consideration, they wouldn't allow skipping commercials either, and Charlie Ergen would not be able to be quoted over and over again as saying that the ability to skip commercials is his favorite feature of PVR's. It's a purely technical issue, which is why I posed a technical question.
First, there doesn't apepar to be an MPEG ENcoder in these boxes. The incoming digital feeds are already encoded, so it would only be needed to record the AUX input or analog TV, and you can't do that.

Second, the discussion moved towards the software design limitations that I believe are preventing this from working - even though I think we all agree that it would be a VERY confusing thing for the 'average' user. It's absolutely nothing to do with chipsets or the like.

So, why didn't they do it? Either because it's a bad (confusing) feature, OR, as I suspect, It would be nutso to track the channel info while surfing, OR both.

As for the political motivations - Charlie's on a tightrope - after all didn't TiVo version 2 drop the 30-second skip feature???
 
TyroneShoes said:
Huh?

TyroneShoes said:
I don't see how any of this even begins to answer the question, which was essentially, "if DVDR's can pause-record and change the source during recordings, why can't PVR's pause-record or change channels without dumping the buffer?". I already proved that changing the input is technically possible without mucking up the recording by using a cable STB.
I never said that technically they can't. My main argument was that from a usability point of view given the medium Tuner integrated into a recordering mechanism that the way they implemented the feature is not as dumb as claimed. I presented some issues that would be a result of not dumping the buffer earlier to support my opinion.

I don't have a DVD recorder but my understanding is that a DVD recorder records video signals that are feed into box. A 508 manages TV channels and allows you to record them. A VCR can also record different streams with out stopping..

TyroneShoes said:
Disregard IRD/PVR's for the moment, as that just complicates the question needlessly. Both a PVR and a DVDR have an MPEG encoder and a decoder, and a medium to record on, and both use the same techniques to record and play back. They likely even use the same chipsets in many cases. They are technical siblings, not identical twins, but nearly fraternal. Only the OS seems to be what keeps PVR's from having this capability.
Well there are different types of PVRs and i am talking at the moment about the 508. It does not have a MPEG encoder it in as someone pointed out and it has a integrated tuner Dish Tuner Which DVDrs do not have. They may serve similar purposes but are not the same thing. Using the same chipsets has nothing to do with why this features works they way it does.

I disagree that they are fraternal twins.. They are different and not related in my opinion thought they have overlapping feature sets. Maybe 2nd cousins. ;)

As for the OS, this feature working the way it does has nothing to do with the OS either. Not sure how you came up with this conclusion. Mind enlighting me on this one.

TyroneShoes said:
Also, disregard any political motivations for not allowing pause. If that were a consideration, they wouldn't allow skipping commercials either, and Charlie Ergen would not be able to be quoted over and over again as saying that the ability to skip commercials is his favorite feature of PVR's. It's a purely technical issue, which is why I posed a technical question.

My understanding is that there is actually data encoded in the stream to tell when commercials are coming. This is how the local stations can add there own commercial feeds. So yes one could tie into that mechanism and it would work pretty good. However, just like VCRs the media giants would come after you faster than you can say 30 second skip. 30 second skip is actually one way of getting the same thing (sort of). Like Simon said, TIVO had it and then disabled it because of pressure. I understand you can hack it back in, but default TIVO box does not have it.

Yes it is a technical issue to remove commercials.. Yes it can be done, but I don't see anyone adding that feature in for legal reasons.. So you have to take political issues when discussing this feature because the reason it is not in PVRs is purely political.
 
WeeJavaDude said:
... My understanding is that there is actually data encoded in the stream to tell when commercials are coming. This is how the local stations can add there own commercial feeds. So yes one could tie into that mechanism and it would work pretty good. However, just like VCRs the media giants would come after you faster than you can say 30 second skip. 30 second skip is actually one way of getting the same thing (sort of). Like Simon said, TIVO had it and then disabled it because of pressure. I understand you can hack it back in, but default TIVO box does not have it.

Yes it is a technical issue to remove commercials.. Yes it can be done, but I don't see anyone adding that feature in for legal reasons.. So you have to take political issues when discussing this feature because the reason it is not in PVRs is purely political.
Yes, there's a blip to tell the locals when to insert their local commercials, but I'm not so sure there's one to indicate when the network-level commercials are coming.
 
SimpleSimon said:
So, why didn't they do it? Either because it's a bad (confusing) feature, OR, as I suspect, It would be nutso to track the channel info while surfing, OR both.

Why would it be confusing? It would actually be simpler than now. No dialog boxes every time you want to change channels. You would use the pause, play, skip, ff, and rewind buttons, exactly the same as now. Except, you would be able to back up past channel changes.

I would think that if the sw/hw could handle the actual channel changes to the buffer, it would be able to track them.
 
GaryPen said:
Why would it be confusing? It would actually be simpler than now. No dialog boxes every time you want to change channels. You would use the pause, play, skip, ff, and rewind buttons, exactly the same as now. Except, you would be able to back up past channel changes.

I would think that if the sw/hw could handle the actual channel changes to the buffer, it would be able to track them.

Pressing rewind resulting in a channel changes would not be expected behavior as I see it. Example: User is on Channel 2, hits rewind and since there is a channel change in the buffer it jumps him to channel 4 (In the buffer). He then watches what was on channel 4 for a bit then it jumps back to channel 2 automatically. You think the average joe would not get confused?

Running this through my mind is given me the chills. :yikes . I think you might be given too much credit to the average user.
 
GaryPen said:
Why would it be confusing? It would actually be simpler than now. No dialog boxes every time you want to change channels. You would use the pause, play, skip, ff, and rewind buttons, exactly the same as now. Except, you would be able to back up past channel changes.

I would think that if the sw/hw could handle the actual channel changes to the buffer, it would be able to track them.
Well, I don't know where to begin. A few of us have turned this thread into a technical discussion of the whys and wherefors of the issues with doing this.

I haven't seen you comment on any of that, so I'm going to make an assumption that you're not a programmer. The programmers posting here do see the issues involved, even when we don't necessarily agree on some of the details - especially those that we're just speculating upon.

The biggest issue to me centers around the fact that channel info is stored with recorded events and the mechanism by which that is done. Suffice it to say that there is a finite number of 'starts' that the box can handle. How many? I've got no clue, but I KNOW it's finite.

Let me switch gears for a moment. The 501 started out with a very limited number of events allowed. They brought out an update that increased that to 50 if I remember right. Why still only 50? No clue - it's a strange number for sure. The 921 only allows 64 (if I remember right). Again, not enough, but at least that's a 'round' number (to a programmer). Why 64? Well, my first thought is that the high-order 2 bits of some 1-byte pointer are in use for something. It's an obsolete technique and I sincerely hope I'm wrong, but all things considered, it makes sense.

It reminds me of why the Y2K bugs came up. Storage was so expensive that saving the 1-2 bytes (depending on data encoding) for 'century' was a real big deal. We knew when we wrote those programs 30 years ago, that they'd be in trouble at the turn of the century, but we never dreamed they would still be around.
 
SimpleSimon said:
It reminds me of why the Y2K bugs came up. Storage was so expensive that saving the 1-2 bytes (depending on data encoding) for 'century' was a real big deal. We knew when we wrote those programs 30 years ago, that they'd be in trouble at the turn of the century, but we never dreamed they would still be around.
It had nothing to do with storage. It was a conspiracy by the programmers of the day to insure that they would have part-time jobs when they retired.
 
Big Bob said:
It had nothing to do with storage. It was a conspiracy by the programmers of the day to insure that they would have part-time jobs when they retired.
:haha ROFLMAO - Don't I wish that were true. Nobody wants us old fossils any more. You think I'd be out installing dishes if I still had a cushy programming job? Well, actually, maybe I would - but I wish I had the choice.
 
:eek: :eek: :eek: I give up. :eek: :eek: :eek:

Are all of the threads on this forum this wacky? There must be a gas leak here, because I've never seen such a gaggle of useless, half-assed thoughts by so many different people all in one thread (and most of which seem to be complete non-sequitors) in my life.

I'm not taking it personal (and neither should anyone else regarding this response), but I really was beginning to think that this might be the place to post what I thought was an intelligent question. I guess unless you post it as the thread starter you take the chance that people will think you've hijacked the thread. If so, My bad. Mea culpa.

I'm sure many of you are fine, upstanding citizens with average-to-above intelligence who can actually read and comprehend and then form complete sentences in an intelligent response that actually deals with the issues raised (which there should be a reasonable expectation of when actually quoted), but you'd really never know it by this thread. It's nearly impossible to make a point to people who won't even pretend to pay attention, and instead jump to conclusions and then respond schizophrenically to something you didn't even say, so I'm out.

Absolutely no offense meant to those to whom this does not apply. I know many of you have done and can do much better than what we've seen here. The rest of you know who you are. Wait...I take that back...I don't think the rest of you do know who you are. :D
 

superdish question

Dish Speaks about the 921 Firewire / DishWire Ports

Users Who Are Viewing This Thread (Total: 0, Members: 0, Guests: 0)

Who Read This Thread (Total Members: 1)