XBMC 12 (Frodo) - So What's The Plan?
#16
(2012-04-15, 20:23)margro Wrote:
(2012-04-15, 16:04)Mike Lowrey Wrote: Unfortunately the XBMC pvr plugin for MP only uses a custom webservice instead of the latest and greatest MPExtended which would also give you a web frontend for tv ( and android app support).
Still on my todo list. As far as I can see from the MPExtended TAS API, most of the required calls are there so porting should not be that difficult.
That's good to hear! As i already said, if you need any further methods you can just send me a PN and i will implement them asap! Smile
Quote:The TVServer plugin is indeed 'custom' but that part just works fine.
Aside from a problem i'm experiencing with it(i still need to check what's the reason for that) it's more about the amount of work for the user to get it working.

MPExtended in it's current form is on it's way to be installed on any MP tv server setup with mobile app access (referring to aMPdroid and an upcoming iOS app), it's easily extendable and so also able to support a complete XBMC setup (with windows at least).
Reply
#17
(2012-04-15, 16:04)Mike Lowrey Wrote: On Windows you can choose between MediaPortal TV Server and 4TR both of them work pretty good and are easy to setup. As soon as you want more than analog cable or dvb-t windows 7 mc is a catastrophic failure regarding tv - i since i've used it for a few years.

Haven't tried PVR with XBMC for many months - tried MediaPortal about a year ago and failed miserably (more my downfalls than the software elements I'm sure) - but have to disagree with Mike's comments on W7MC. I'm no lover of Windows products and can't wait until we have PVR in XBMC as standard, but I currently use WMC for live TV and PVR functionality with DVB-S2 and DVB-T tuners and it works brilliantly. In fact the options available make Sky or BT Vision (I'm in the UK) look pretty poor in comparison - I'm sure MediaPortal has more functionality again, but compared to a standard PVR box it's great, imo. The menus hang from time to time (as does XBMC) but apart from that, no complaints.

After reading a couple of threads, I might give 4TR a go and see how I get on - bit reluctant to try MediaPortal another go to be honest.

Looks like it could be an exciting year for PVR on XBMC, so many thanks to the devs involved.
Reply
#18
For The Record + MediaPortal TV Server is currently (in my opinion) the very best solution there is for backends. MePo's TV Server is solid, uses very little memory, supports nearly every modern (and some not so modern) tuner/capture device on the market, and is very stable. It also has very solid plugin support for things like IR blasters.

For The Record sits on top of it (it has a plugin). FTR actually comes with it's own tuner software, called Argus, but it doesn't support nearly as many devices, and there's no analog capture support at all.

However FTR's scheduling, tuning, and web interface options are hard to beat. The only problem with either of them is they are Windows-only - it's not that I have a philosophical issue with Windows, I just like options, and I find Linux based HTPC's (such as XBMCBuntu) to be much easier to deal with day to day. That could just be me though, since I am used to shells and scripting. All that said the FTR/MePo combo is so far ahead of any other backend for XBMC at the moment that I deal with it anyway. Hello remote desktop.
Reply
#19
I'm confused why timeshifting is something that XBMC needs to implement. Isn't that something that the backend needs to implement? As far as XBMC is concerned, it just needs to connect to a buffered stream instead of a live stream. The interface would need a pause button, but that would simply send commands to the backend.

Attempting to buffer live video on the frontend would start causing major issues as the frontend is most likely not the proper place to store TS streams.

MUCH of the complexity could be removed by simply having the backend be the buffer.

Some of the backends already support this. TVHeadend will allow you to play the live stream if you're recording it. They have some issues to work out (You can't see the proposed end of the stream, it simply updates the stream length on the fly, but it DOES allow for a bit of time shifting)

I've heard that VDR also is allowing a bit of this.

I'm not trying to troll, I'm just asking what are the other tech hurdles I'm not thinking of?
Reply
#20
MediaPortal would support that since the buffer is server based. XBMC has to support going back in time and checking the available timespan of the timeshift buffer.
Reply
#21
Indeed, the only thing that I need to support timeshifting with the MediaPortal addon and the ForTheRecord addon is an extension of the PVR API to forward the "pause", "forward" and "rewind" commands from XBMC to the addon. Both Windows backends already do the timeshifting (buffering) and the addons already read from the timeshift buffer.
The missing functionality was actually already available in very early versions of the PVR branch, but Alwinus removed it because it didn't work properly. I still have a local branch on my computer with a more or less working timeshift functionality. The only thing that I have to fix is to limit the rewind and forward to the buffer contents for the current channel. Right now, I can even rewind to the previous channel :-)
Developer of the MediaPortal PVR addon and retired developer of the Argus-TV PVR-addon.
http://www.scintilla.utwente.nl/~marcelg/xbmc
Reply
#22
This is excellent news! Is it really a problem that the rewind override to the previous channel? Doesn’t Mediaportal behave that way?
Reply
#23
Margro - please do not limit the TS buffer to only the current channel. Buffer is buffer - no matter which channel. On MediaPortal I often have the situation that I'm ~ half an hour behind in the TS buffer and a new show is starting on a different channel. Then I just jump to "live", switch channel and go back in the buffer to watch the rest of the show on the other channel. So why would one want to limit the buffer to the current channel and loose everything even on probably just a occasional channel switch? The displayed stream/buffer length etc ofc can be limited to the currently running show/channel, but the buffer itself should be kept and "browseable".

PS any chance to get hands on your local timeshift patch? I'd just love to finally drop MP, but I need timeshift Smile I can compile myself and use 4TR Argus.

BTW - can't Argus record one channel and allow watching another channel on the same DVB-S transponder? It used to work with any software or settop box I know of - also missing this a bit.
Reply
#24
@da-anda: I understand your usage but this is a bit more complicated to implement.
Right now, the addon just reads the TV stream as binary data without knowledge about its contents (streams, HD, SD etc.). On every channel switch, the amount of streams might change and also SD<->HD. XBMC does all the demuxing and does not expect sudden stream changes without an initiated channel switch. To support rewinding to the previous channel, I have to parse the timeshift buffer for channel changes and tell XBMC that it should restart the demuxer when I'm seeing a different channel. Not impossible to implement but this is much more work than first limiting the timeshift capabilities to the current channel.

W.r.t. your FTR question: Don't know. I'm actually not a ForTheRecord user, only one of the two addon developers Smile
Developer of the MediaPortal PVR addon and retired developer of the Argus-TV PVR-addon.
http://www.scintilla.utwente.nl/~marcelg/xbmc
Reply
#25
(2012-04-17, 15:24)margro Wrote: <~snip>
The missing functionality was actually already available in very early versions of the PVR branch, but Alwinus removed it because it didn't work properly. I still have a local branch on my computer with a more or less working timeshift functionality. The only thing that I have to fix is to limit the rewind and forward to the buffer contents for the current channel. Right now, I can even rewind to the previous channel :-)

Could you elaborate a bit more on this? I've read hints about this in other posts. What didn't work properly? The whole subject of the former PVR code that was removed has kinda been reduced to "lore" in these forums so I'd love to hear more about it.

Reply
#26
(2012-04-18, 02:31)nobleach Wrote: Could you elaborate a bit more on this? I've read hints about this in other posts. What didn't work properly? The whole subject of the former PVR code that was removed has kinda been reduced to "lore" in these forums so I'd love to hear more about it.
It was work-in-progress code from Alwinus (Alwin Esch) for usage together with the VDR pvr addon (the original starting point of the PVR branch, named pvr-testing2 in SVN).
I'm not sure, but I think his original plan was to implement the timeshifting at the XBMC side and he abandoned that idea and removed his initial implementation.

The PVR API had a few additional functions like PauseLiveStream() (if I remember correctly...) I can't even find it back in SVN but it was around the time of this commit:
29132

The current API has still a few functions that are ment for positioning the livestream:
SeekLiveStream()
PositionLiveStream()
LengthLiveStream()
so part of the required functionality is still there but currently not used.
Developer of the MediaPortal PVR addon and retired developer of the Argus-TV PVR-addon.
http://www.scintilla.utwente.nl/~marcelg/xbmc
Reply
#27
(2012-04-18, 12:35)margro Wrote:
(2012-04-18, 02:31)nobleach Wrote: Could you elaborate a bit more on this? I've read hints about this in other posts. What didn't work properly? The whole subject of the former PVR code that was removed has kinda been reduced to "lore" in these forums so I'd love to hear more about it.
It was work-in-progress code from Alwinus (Alwin Esch) for usage together with the VDR pvr addon (the original starting point of the PVR branch, named pvr-testing2 in SVN).
I'm not sure, but I think his original plan was to implement the timeshifting at the XBMC side and he abandoned that idea and removed his initial implementation.

The PVR API had a few additional functions like PauseLiveStream() (if I remember correctly...) I can't even find it back in SVN but it was around the time of this commit:
29132

The current API has still a few functions that are ment for positioning the livestream:
SeekLiveStream()
PositionLiveStream()
LengthLiveStream()
so part of the required functionality is still there but currently not used.
I've updated the CPVRClients class in my repo to make use them. It seems to be working with my mythtv addon except the timeline doesn't follow the position. Not sure how the other addons will function with the patch though (as they use a stream url instead of a file access.)
Libcmyth MythTV addon for xbmc-pvr [source] [forum thread]
Reply
#28
(2012-04-17, 16:51)da-anda Wrote: Margro - please do not limit the TS buffer to only the current channel. Buffer is buffer - no matter which channel. On MediaPortal I often have the situation that I'm ~ half an hour behind in the TS buffer and a new show is starting on a different channel. Then I just jump to "live", switch channel and go back in the buffer to watch the rest of the show on the other channel. So why would one want to limit the buffer to the current channel and loose everything even on probably just a occasional channel switch? The displayed stream/buffer length etc ofc can be limited to the currently running show/channel, but the buffer itself should be kept and "browseable".

PS any chance to get hands on your local timeshift patch? I'd just love to finally drop MP, but I need timeshift Smile I can compile myself and use 4TR Argus.

BTW - can't Argus record one channel and allow watching another channel on the same DVB-S transponder? It used to work with any software or settop box I know of - also missing this a bit.

I dont think this is necessary, why don't you just jump over to epg and schedule a recording for the show you want to watch later? I think timeshifting is more a compromise for short times like stopping to go and pee and jump back to live tv when the next commercial starts...
Reply
#29
that won't work, because only having 1 DVB-S2 card would require a channel switch to perform the recording - and a channel switch would then erase the TS buffer.
Reply
#30
(2012-04-06, 17:13)dushmaniac Wrote:
(2012-04-05, 20:19)XBMCUser4657 Wrote: [*]No extra backend software needed. XBMC could pull directly from my HD Homerun tuners and the DVR functionality could be configured directly within XBMC
if you write an add-on that can interface directly with the hdhomerun, sure, but then the hdhomerun will be the backend. XBMC will not get an internal backend, since there's no reason to spend time on that. Configuring the backend from within XBMC is certainly something that can use some love, but there's no reason to include a PVR backend in XBMC itself.

Quote:[*]No more Live TV standalone menu....would love this to be integrated into my Videos menu where I see a sub-menu for Live TV, TV Shows, Movies, etc.
as far as I can see, you can already do that by modifying the skin

Quote:[*]Recordings which can be configured with a name schema, then have metadata scraped. They would then seamlessly integrate into the Videos library in the appropriate location. I believe this is the whole universal front-end concept.
that's on the long term planning, but needs quite some changes in the interface

Quote:[*]Please enable reliable timeshifting. This is the single biggest current gap!
not even going to look into this right now, not before PVR is in mainline in it's current form (after more cleanups, reviews, etc)

Quote:[*]Series scheduling would be awesome. More sophisticated series scheduling (where it looks for only new episodes, or actually looks for the name of the show instead of a straight-up recurring time slot) would be even sweeter
same remark as with the recordings

Quote:[*]Have XBMC offer a reliable and easy-to-configure EPG pull - is this even possible?
what do you mean?

Quote:[*]Enable an easier way for the EPG to color by show category (without having to go to an XML config file)
this must be something specific to the backend that you're using. when you use tvheadend as backend, you get a coloured epg without configuring anything.

the focus for Eden was to get a stable and proper PVR build that's good enough for daily usage, which I think it is now. now, the focus for me for Frodo is not to add any new features, but clean up the current tree where needed/desired, and get it merged into mainline. I'll include minor changes that are sent via a PR if they're ok, but won't include any big changes right now that change the current behaviour.

(2012-04-23, 00:35)Hasu0bs Wrote:
(2012-04-17, 16:51)da-anda Wrote: Margro - please do not limit the TS buffer to only the current channel. Buffer is buffer - no matter which channel. On MediaPortal I often have the situation that I'm ~ half an hour behind in the TS buffer and a new show is starting on a different channel. Then I just jump to "live", switch channel and go back in the buffer to watch the rest of the show on the other channel. So why would one want to limit the buffer to the current channel and loose everything even on probably just a occasional channel switch? The displayed stream/buffer length etc ofc can be limited to the currently running show/channel, but the buffer itself should be kept and "browseable".

PS any chance to get hands on your local timeshift patch? I'd just love to finally drop MP, but I need timeshift Smile I can compile myself and use 4TR Argus.

BTW - can't Argus record one channel and allow watching another channel on the same DVB-S transponder? It used to work with any software or settop box I know of - also missing this a bit.

I dont think this is necessary, why don't you just jump over to epg and schedule a recording for the show you want to watch later? I think timeshifting is more a compromise for short times like stopping to go and pee and jump back to live tv when the next commercial starts...

The way I've always used timeshifting is having an hour long scheduled recording and jumping into it 20 minutes late, skipping all the commercials and "catching up" at the end of the show.

The other use case would be starting a show, pausing it, putting the kids to bed, then returning (and probably skipping a few commercials now that some time has been built up in the buffer)

As far a having a universal buffer that encompasses all channel changes, I'm not a big fan of this. EyeTV's DVR software does this, and I hate it. I've used a TiVo for 10 years, and I'm used to the buffer flushing at each channel change. I'd probably be happy either way though.

-nobleach
Reply

Logout Mark Read Team Forum Stats Members Help
XBMC 12 (Frodo) - So What's The Plan?0