Pausing Live TV streams

[osx-addict]

So, yesterday was my first time getting NPVR + XBMC working together (albeit on the same machine).. One thing I noticed that I thought was a bit odd was the I was not able to pause/rewind live TV like I can do on various other PVRs (Tivo/SageTV,etc).. The buttons were on screen but were greyed out.. I did a quick search and wasn't sure if this was correct or not.. When using the Frodo build + the NPVR plugin, should I be able to pause/rewind live TV?

Thanks!

[sub]

When using the Frodo build + the NPVR plugin, should I be able to pause/rewind live TV?

No, you shouldn't be able to pause/rewind live tv with the NPVR addon.

XBMC's live tv capabilities did not have support for this until about two weeks ago, when it was rushed in at the last minute before the Frodo feature freeze. Unfortunately it's a poor implementation, more suited to addons using RTSP, which caused grumblings from other addon developers (and I agree). There seemed to be some agreement that it wasn't ideal, but it was too late to change it. This change was based on some old work done by a developer a year or so ago for the MediaPortal and 4therecord addons, which why these addons have been able to add support for it so quickly.

It's unknown at this stage if I'll be adding support for it in the NextPVR addon. I'll need to experiment to see if its possible to work with the interfaces they've provided.

[osx-addict]

So that's not to say, at some point, the API could change to allow such a feature.. I guess we can hope!

BTW - Thanks for the info!!

[KRA]

This is really frustrating (don't take this as an attack on you Sub)

Marcel (MP plugin and FTR co developer) said (a long time ago) that every backend that has built in support for Timeshifting could use his code to implement timeshifting, if this hit feature freeze in a state that only works for 2 out of several backends it's not cool, kindo pisses me off. And not only that, but FTR plugin is currently broken because of limited curl features. So all we are left with is MP backend. Why the hell did they have to wait so long to pull in and evaluate the code, it was done ages ago.

And how hard can it really be ? XBMC already has excellent capability to pause/seek in both streamed content, and content read off the HD. What's so different for live-tv ?

Even in VLC I can pause live-tv from NPVR, although only for about 15 seconds, I guess the backend stops at that point, because VLC isn't asking for data anymore.

Why o why is it so hard for XBMC to do it ? From a none programmer pov it seems really simple, pause/seek is already in xbmc, I would think all you need to do is tell the backend to keep timeshifting (like a hartbeat or ping kindo thing to keep it alive). But then again, I have no idea how this stuff works, I just come on forums and rant about missing features and problems.

[osx-addict]

I was thinking about what sub said this morning on my way back to work -- I was wondering IF sub (and others) were to design a new API that would do ALL of what NPVR wanted and what other plugin developers are looking for, why not allow a 2nd API that is :

1) More focused on non-RTSP streams (makes NPVR plugin easier/better,etc) -- per Sub's comments above
2) Eliminates existing shortcomings (not that I know what they might be)
3) Allows for future growth for plugins (more flexibility,etc)

KRA - I realize this may sound simple on the surface for a non-programmer type of person (as you mention above), but sometimes the code beneath the hood can be a PITA to deal with -- not that I'm implying that here-- I've never looked at any of the XBMC code outside of a little bit of the NPVR plugin with the hopes of porting it to OSX soon. My day job is doing software development with GCC/G++ (almost exclusively C++) on Solaris + PPC (VxWorks) and has been that way for the past 15+ years. I've had my fair share of UGLY code and I suspect in this case there are other factors involved behind the scenes that Sub didn't mention. It's also more difficult when you get a fairly large pool of developers involved as each will have their own way to solve problems -- some good some not so good..

What I'm hoping is that Sub will continue with being a very proactive developer (such as I've seen so far) and run with his good ideas that he's got. I don't know what the underlying architecture is for either XBMC or NPVR to interject ideas but I'm assuming there are handfuls of threads running around behind the scenes working as client & servers to make what we think is a great combo -- just work.

Sorry for the long explanation.. I can only hope that perhaps Sub can wish up a new API to meet the needs of NPVR+XBMC and see if it flys with other plugin developers..

Sub : While I don't know Windows directly, I do know Linux & Unix in general (various flavors) and would like (as time permits) to get involved in what I believe is a great software combo! I'm going to start out with the NPVR/XBMC plugin and try to get it going for OSX to get my feet wet and see what I can glean from the code..

[wileecoyote]

This is really frustrating (don't take this as an attack on you Sub)

Marcel (MP plugin and FTR co developer) said (a long time ago) that every backend that has built in support for Timeshifting could use his code to implement timeshifting, if this hit feature freeze in a state that only works for 2 out of several backends it's not cool, kindo pisses me off. And not only that, but FTR plugin is currently broken because of limited curl features. So all we are left with is MP backend. Why the hell did they have to wait so long to pull in and evaluate the code, it was done ages ago.

And how hard can it really be ? XBMC already has excellent capability to pause/seek in both streamed content, and content read off the HD. What's so different for live-tv ?

Even in VLC I can pause live-tv from NPVR, although only for about 15 seconds, I guess the backend stops at that point, because VLC isn't asking for data anymore.

Why o why is it so hard for XBMC to do it ? From a none programmer pov it seems really simple, pause/seek is already in xbmc, I would think all you need to do is tell the backend to keep timeshifting (like a hartbeat or ping kindo thing to keep it alive). But then again, I have no idea how this stuff works, I just come on forums and rant about missing features and problems.

I do agree with the first part, I find it disheartening that they would allow proprietary code (i.e. MediaPortal & FTR specific code) into XBMC. I thought the XBMC developers were more open minded and would want a broad scope of timeshifting that would work with all back-ends.

I would have been happier if they didn't implement timeshifting at all in the first revision. It's going to be harder to re-do what has already been done...

As far as implementation, its not that easy. If you watch MediaPortal or NPVR timeshift folders you will see that as time goes on more files are created. The front end needs to know how to handle these files and which order to play/rewind/ff etc... It's a little more complicated than reading a stream directly (i.e. a video file on a server that doesn't change dynamically.)

[KRA]

I started testing xbmc-pvr over 2 years ago, and tbh it's starting to frustrate me a lot. From a none developer pov not much has changed in that time. PVR release of xbmc was pushed back and pushed back, then suddenly it's rushed in right before feature freeze of Frodo, wtf ?

I really like the idea of a unified xbmc frontend that can use any backend via plugin, but in it's current state xbmc-pvr is rather poor feature wise imho. It seems to me xbmc-pvr was created several years ago by someone who had little experience with other pvr software. Really the xbmc-pvr devs should take a look at the "competition" out there and see what different frontends can do (Mediaportal, NPVR, MyhTV etc). There are some really cool features they provide, and the amount of time and fuss to implement something "as simple as" timeshifting in xbmc-pvr makes me fear the future. If xbmc wasn't crossplatform I would not be using it. My only hope is that once Frodo is released, interest and development on pvr will explode and provide plenty of new and advanced pvr features.

[osx-addict]

I do agree with the first part, I find it disheartening that they would allow proprietary code (i.e. MediaPortal & FTR specific code) into XBMC. I thought the XBMC developers were more open minded and would want a broad scope of timeshifting that would work with all back-ends.

I did not know that (I'm a newbie to both XBMC+NPVR) -- I know many a project have allowed that in the past using multiple license schemes to cover where all of the code originated but most eventually kick that code out and bring it back under a single license to simplify things -- seems like a slippery slope. XBMC developers ought to hold their ground and not allow in code that has different licensing and end-uses.

I would have been happier if they didn't implement timeshifting at all in the first revision. It's going to be harder to re-do what has already been done...

I agree -- the implementation is likely to be leaning towards those two sets of code to help their end-goal but not necessarily be in the best interest of anyone else -- not a good path to go down. I think those two groups ought to fend for themselves and let the rest of the plugin developers make the API in their own best interest..

Sub - are there any docs available, that you're aware of, describing the architecture of either side of the equation (NPVR by itself, XBMC by itself, XBMC plugins,etc)? Just curious..

[KRA]

As far as implementation, its not that easy. If you watch MediaPortal or NPVR timeshift folders you will see that as time goes on more files are created. The front end needs to know how to handle these files and which order to play/rewind/ff etc... It's a little more complicated than reading a stream directly (i.e. a video file on a server that doesn't change dynamically.)

I get that, I don't know how the NPVR plugin works, if it's streamed or read the TS files directly via share or what. But why use more than one TS file ? Are there still people using FAT32 ? Why not just have one file, it would be super easy, just make sure the backend is timeshifting and the plugin just reads that one file. I know there are some issues with how you open and read from files that are growing, maybe it's filesystem related I don't know ? Everything seems so simple to me

[osx-addict]

...My only hope is that once Frodo is released, interest and development on pvr will explode and provide plenty of new and advanced pvr features.

I agree here.. I had not laid eyes on XBMC before about a year ago and it wasn't able to use any of my backend hardware at the time and NPVR of course wasn't able to use it either so I let both be.. I like the capabilities of NPVR by itself albeit the front end doesn't have the 'fan' (almost cult-like) following that XBMC has for whatever reason. I guess one of the reasons I am interested, for the first time -- in a long time with XBMC as software is t hat it's open-source/cross platform and is loaded with potential care of all of the developers out there.. I think it has potential to be one of the best media/set top box packages out there -- but it's only as good as the backend is capable (and the plumbing in between).. IMHO.