2012-12-21, 18:07
Just a few general comments.
1. Timeshift buffer is currently a permanent ring buffer upto the specified limits. Much like a standard pvr. I'm going to eventually add an option for pause only.
2. Performance of timeshift seeking will be slightly quicker with local and/or SSD drive. But for most use cases it'll be negligible.
3. HD content is about 1-2MBytes per second. So 4-5GBytes an hour typically. So base space requirements on that.
4. Stuttering playback can occur depending on video playback settings. I'm still trying to figure optimal for my own machines.
5. There are definitely issues with playback after fd/rwd. Not sure where the fault lies at this stage.
6. I wouldn't call the code stable, but since its starting to be used and doesn't seem to be doing too badly I think I may merge to master in the next few weeks.
Finally there is definitely a long way to go for a truely seamless timeshift, both in tvh and xbmc. But I think by at least having something we can begin that progress.
Adam
1. Timeshift buffer is currently a permanent ring buffer upto the specified limits. Much like a standard pvr. I'm going to eventually add an option for pause only.
2. Performance of timeshift seeking will be slightly quicker with local and/or SSD drive. But for most use cases it'll be negligible.
3. HD content is about 1-2MBytes per second. So 4-5GBytes an hour typically. So base space requirements on that.
4. Stuttering playback can occur depending on video playback settings. I'm still trying to figure optimal for my own machines.
5. There are definitely issues with playback after fd/rwd. Not sure where the fault lies at this stage.
6. I wouldn't call the code stable, but since its starting to be used and doesn't seem to be doing too badly I think I may merge to master in the next few weeks.
Finally there is definitely a long way to go for a truely seamless timeshift, both in tvh and xbmc. But I think by at least having something we can begin that progress.
Adam
