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.