510 Buffer Question

  • WELCOME TO THE NEW SERVER!

    If you are seeing this you are on our new server WELCOME HOME!

    While the new server is online Scott is still working on the backend including the cachine. But the site is usable while the work is being completes!

    Thank you for your patience and again WELCOME HOME!

    CLICK THE X IN THE TOP RIGHT CORNER OF THE BOX TO DISMISS THIS MESSAGE

GaryPen

Rich or poor, it's good to have money.
Original poster
Supporting Founder
We recently ordered a 510, and were wondering whether it will be possible to rewind a current show to the beginning, after it's been on for about 10-15 minutes. Then, watch it and skip the commercials until we catch up to the live feed, presumably at close to the end of the program.

A friend with a DirecTivo tells me he can do it with his. We hope we can do it with the 510.
 
What the hell are you talking about n0qcu, that has nothing to do with it.

Yes you can. The show could be recording and you could be watching it, or something else previously recorded then about 15 mins in, you switch back to the recording show, (or rewind, whatever the case may be) and start watching it, skipping commercials.

In fact, I do this a lot, even if you plan to watch something "live", don't. Pause it, go do some things you have to get done then come back and save yourself some time.
 
AppliedAggression said:
What the hell are you talking about n0qcu, that has nothing to do with it.
His question was if he could back up a cuurent show 10 - 15 minutes.

my answer was correct.
 
Thank you both. n0qcu, you were apparently correct. But, you didn'r really answer my question. I was aware of the 1 hour buffer. What I wanted to know is whether that would enable me to do what AA has confirmed I can.
 
Not only that, but you can convert the buffer to a regular recording after the fact. Rewind up to an hour and press "record", and its just as if you pressed record an hour ago.
 
GaryPen said:
Unh. No. It doesn't. When changing channels, it starts the buffer all over again, losing whatever you were buffering to that point.
Ah! Now I see. You want it to keep a buffer of the last hour regardless of channel surfing. Nice idea. Probably too hard to implement, but a neat feature.
 
Well, by observation, video files are stored "by channel". Considering the overall design flaws in these receivers, I'll bet a donut that the channel info is tied way too closely to the file system. Of course, I lost my last donut bet.
 
I'm sure that any real consumer electronics company would have been able to easily impliment a 60 minute buffer that recorded everything, including channel changes. But, as Dish does not know how to design consumer electronics properly, you are no doubt correct. But, even if it isn't the channel info that's the root of this shortcoming, it's probably something else incredibly stupid.
 
GaryPen said:
I'm sure that any real consumer electronics company would have been able to easily impliment a 60 minute buffer that recorded everything, including channel changes. But, as Dish does not know how to design consumer electronics properly, you are no doubt correct. But, even if it isn't the channel info that's the root of this shortcoming, it's probably something else incredibly stupid.

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?

Does TIVO buffer or Reply work like this? I don't see this as another reason why D* cannot do software development, but as a design decision in which they chose to implement certain way to provide a certain set of features (Ability to rewind on the current program you are watching and dump it to disk if you so desire). From a conceptional point of view I am sure it seems easy. However, from a usability point of view it has some issues.

1) When you rewind back on the buffer and there is a channel change how is that indicated to the user so that it does not seem confusing? This would require some type of meta-data on the stream itself to provide this feature. If implemented they way you are expecting, I would find this rather confusing and annoying.

2) What about the person that changes channels a lot.. Boy I could see the buffer feature becoming useless very fast.

3) How do you handle the feature when you go back to the beginning and it dumps the buffer to the hard disk if that buffer is made up of 10 channel changes. Yes you could dump all ten as seperate events but most likely that is not what you would like and wourld require more user intervention when dumping the stream or after the fact cleaning up all the 2 minute channel changing recordings it found.

4) My guess is that each of these channels is a seperate MPEG-2 stream that would have to be stitched together. I could see performance degregration occuring if lots of channel changing occurrs. UGH!

Yes you could have implemented the buffer as just the last hour of recording including your random channel changes etc. but I see that doing this also removes a lot of usefullness from the feature in itself and adds some rather nasty usability inconsistencies and possible some performance implications.
 
I've never understood this practice...it must be because it just gets too complicated for the garden-variety consumer to manage all of the potential buffer clips, is why all PVR's simply dump on a channel change. You can't pause a PVR, either. When I got my first Tivo that was my only real complaint...my VCR at the time could actually pause-record WITH SHUTTLE, allowing real-time removal of commercials during a recording...very cool. I was shocked when I couldn't even pause my Tivo.

DVDR's use very similar recording techniques (albeit to a completely different medium) to PVR's, and they can pause-record, and you can change channels during the pause if you like, so there is no technical limitation to either pausing a PVR or not dumping on a channel change.

Here's one workaround:

I have an old ShowStopper at work that I have connected to a cable STB. I can change channels using the cable remote as much as I like, and the buffer (which is as long as the space not currently used on Replay's and ShowStopper's) never dumps. Seems that since I brought in the ShowStopper I'm getting less work done, however.
 
TyroneShoes said:
DVDR's use very similar recording techniques (albeit to a completely different medium) to PVR's, and they can pause-record, and you can change channels during the pause if you like, so there is no technical limitation to either pausing a PVR or not dumping on a channel change.

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.
 
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?
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)...
WeeJavaDude said:
Does TIVO buffer or Replay work like this? I don't see this as another reason why D* cannot do software development, but as a design decision in which they chose to implement certain way to provide a certain set of features (Ability to rewind on the current program you are watching and dump it to disk if you so desire). From a conceptional point of view I am sure it seems easy. However, from a usability point of view it has some issues.

1) When you rewind back on the buffer and there is a channel change how is that indicated to the user so that it does not seem confusing? This would require some type of meta-data on the stream itself to provide this feature. If implemented they way you are expecting, I would find this rather confusing and annoying.
Quite right, but the metadata is already there. I don't remember exactly for the 5xx series, but on a 921, the program info for that moment is there - try a manual timer that crosses several shows, you'll see. :) It'd be interesting to know what happens to that metadata when the buffer crosses show boundaries.
WeeJavaDude said:
2) What about the person that changes channels a lot.. Boy I could see the buffer feature becoming useless very fast.
Quite right again - and the biggest reason not to do it I think.
WeeJavaDude said:
3) How do you handle the feature when you go back to the beginning and it dumps the buffer to the hard disk if that buffer is made up of 10 channel changes. Yes you could dump all ten as seperate events but most likely that is not what you would like and wourld require more user intervention when dumping the stream or after the fact cleaning up all the 2 minute channel changing recordings it found.
The buffer is already on hard disk. Other than that, you're right, there's some issues there.
WeeJavaDude said:
4) My guess is that each of these channels is a seperate MPEG-2 stream that would have to be stitched together. I could see performance degregration occuring if lots of channel changing occurrs. UGH!
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.
WeeJavaDude said:
Yes you could have implemented the buffer as just the last hour of recording including your random channel changes etc. but I see that doing this also removes a lot of usefullness from the feature in itself and adds some rather nasty usability inconsistencies and possible some performance implications.
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:
 
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. :(
 

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

Who Read This Thread (Total Members: 1)

Latest posts