[cncb]

It seems like the playback of active recordings is "streamed" like Live TV where there is only a small buffer and the current total recording time is not displayed. I can't skip ahead in the recording and if I stop I can't resume from where I left off.

I tried a different backend and it behaves a little differently for active recordings in that it shows the total recording time when you initially start playback and you can skip ahead up until that point. When you reach the initial recording length/time you can watch past that point but if you try to skip ahead it jumps back to the initial recording time and if you stop it thinks that the whole recording was watched and you can't resume.

Maybe it is not possible with XBMC but is there any way you can get the same behavior as when watching the active recording in WMC on the server? That is, constantly update the recording length, allow skipping ahead until you catch up with the current recording point, and allow resume if you stop? Thanks.

[krustyreturns]

It seems like the playback of active recordings is "streamed" like Live TV where there is only a small buffer and the current total recording time is not displayed. I can't skip ahead in the recording and if I stop I can't resume from where I left off.

I tried a different backend and it behaves a little differently for active recordings in that it shows the total recording time when you initially start playback and you can skip ahead up until that point. When you reach the initial recording length/time you can watch past that point but if you try to skip ahead it jumps back to the initial recording time and if you stop it thinks that the whole recording was watched and you can't resume.

Maybe it is not possible with XBMC but is there any way you can get the same behavior as when watching the active recording in WMC on the server? That is, constantly update the recording length, allow skipping ahead until you catch up with the current recording point, and allow resume if you stop? Thanks.

We have a weakness here that your other pvr solution likely doesn't. Active wtv files are not playable by xbmc, they will either quit prematurely or crash depending on your luck. We solve this problem by remuxing to ts on the fly, so when you start watching an active recording you don't really have a bunch of data ready to play, you have to wait for the remux to generate data. The remux is fast it will catch up to the where the recording currently is pretty quickly, but its still annoying to wait. So if you start watching an active recoriding hit pause, come back in 5 minutes, and you can start skipping forward. I know that sucks.

A solution I have been thinking about for this is to start a remux process whenever a new recording is happening. But only remux for a fixed about of time, say 10 minutes, then halt the remux where it is. If the user (you) start watching the active recording the remux is restarted where it left off, but you have 10 minutes of video you could step through, in the mean time the remux with its big head start is racing ahead. I figure I could make this amount of time to buffer a setting.

Interested to hear what people think.

[cncb]

Thanks for the reply. I understand the issue now. It seems like you would run into the same problem when you reach the end of the initial 10-minute buffer. That is, you would no longer be able to skip ahead until you restart playback and resume probably would not work?

[krustyreturns]

Thanks for the reply. I understand the issue now. It seems like you would run into the same problem when you reach the end of the initial 10-minute buffer. That is, you would no longer be able to skip ahead until you restart playback and resume probably would not work?

I don't think so. Because when you start watching the active recording, the remux would restart where it left off. It would have a 10min headstart over your viewing, even if you started skipping I doubt you would catch up. If you did, do pre-remux 20 minutes next time. Anyway its just a thought.

Resume playback back could be handled too.

[scarecrow420]

Krusty, I was thinking something similar. You could also just create a full TS remux for every recording rather than "pausing remux after 10 minutes" . Once the recording completes, delete the TS file. This would cost more disk space but means you don't have to implement changes to pause/resume the remuxer. Of course have a config option of whether to do this or not "pre-empt instant rec playback". Maybe even a time of day to do this so it doesn't bother doing it when the users are asleep etc

[krustyreturns]

Krusty, I was thinking something similar. You could also just create a full TS remux for every recording rather than "pausing remux after 10 minutes" . Once the recording completes, delete the TS file. This would cost more disk space but means you don't have to implement changes to pause/resume the remuxer. Of course have a config option of whether to do this or not "pre-empt instant rec playback". Maybe even a time of day to do this so it doesn't bother doing it when the users are asleep etc

Yeah I think you are probably right. Certainly easier to code and guaranteed to work the way the user expects (and disk space is cheap - my motto). The time of day thing is an interesting idea too.

[cncb]

I don't think so. Because when you start watching the active recording, the remux would restart where it left off. It would have a 10min headstart over your viewing, even if you started skipping I doubt you would catch up. If you did, do pre-remux 20 minutes next time.

The issue I'm having is that it never seems to "buffer" more than ~20 seconds more than the current position. So, I start playback of an active recording, pause it for several minutes to build up the remux, start playing again and I still can't jump forward 30s or punch in 2:00 to jump to that location since XBMC thinks the video is only ~30 seconds long.

[krustyreturns]

I don't think so. Because when you start watching the active recording, the remux would restart where it left off. It would have a 10min headstart over your viewing, even if you started skipping I doubt you would catch up. If you did, do pre-remux 20 minutes next time.

The issue I'm having is that it never seems to "buffer" more than ~20 seconds more than the current position. So, I start playback of an active recording, pause it for several minutes to build up the remux, start playing again and I still can't jump forward 30s or punch in 2:00 to jump to that location since XBMC thinks the video is only ~30 seconds long.

Oh. I will take another look.

[krustyreturns]

I don't think so. Because when you start watching the active recording, the remux would restart where it left off. It would have a 10min headstart over your viewing, even if you started skipping I doubt you would catch up. If you did, do pre-remux 20 minutes next time.

The issue I'm having is that it never seems to "buffer" more than ~20 seconds more than the current position. So, I start playback of an active recording, pause it for several minutes to build up the remux, start playing again and I still can't jump forward 30s or punch in 2:00 to jump to that location since XBMC thinks the video is only ~30 seconds long.

Oh. I will take another look.

I spent some time looking at this today and found there is no easy fix to this problem when remuxing to ts for an active recording, not without changing xbmc itself. However we have implemented resume in the view version of serverwmc (that we are currently working to release). With this version I am going to add the option to not remux active recordings. When you use this option, you'll be able to fast-forward, rewind, skip all you want, but when you get to the end of what xbmc thinks is the end of the file (the file size when you started viewing), xbmc will stop playing the recording. But when this happens, you just have to start it again and you can instantly start where you left off.

After playing with both today, I decided I like the latter method better and I am thinking of making this the default, but like I said it will be an option. I know its not ideal, but its where we are for the next version at least.

[cncb]

I spent some time looking at this today and found there is no easy fix to this problem when remuxing to ts for an active recording, not without changing xbmc itself. However we have implemented resume in the view version of serverwmc (that we are currently working to release). With this version I am going to add the option to not remux active recordings. When you use this option, you'll be able to fast-forward, rewind, skip all you want, but when you get to the end of what xbmc thinks is the end of the file (the file size when you started viewing), xbmc will stop playing the recording. But when this happens, you just have to start it again and you can instantly start where you left off.

Ok, thanks for looking into this.