XBMC PVR Client & For The Record: Argus TV-Server

Can anyone tell me, is this addon 64 bit friendly (and more specifically, Openelec 64 bit friendly)?

(2012-05-27 13:28)bossanova808 Wrote:  Can anyone tell me, is this addon 64 bit friendly (and more specifically, Openelec 64 bit friendly)?

I documented getting XBMC Live working with the FTR add-on here: http://www.4therecord.eu/forum/viewtopic...=41&t=2228. Somewhere around page 3 some helpful users explain how to get Openelec working.

The current download for Linux (see http://www.4therecord.eu/forum/viewtopic...=41&t=2425) is a x86 shared object. The last time I built on 64 bit Ubuntu was around December 2011/January 2012. I don't know if the current code still builds on 64 bit Linux.

Is there a list (no, not the wiki. though that would be the best place for it) of current backends and the features that currently work? Perhaps even what is being worked on next?
I'm trying to decide on MP or FTR and it sounds like the latter is easier to get working without stuttering, but I can't find a list of what works in both.

Thank you

(2012-06-01 17:50)tismon Wrote:  Is there a list (no, not the wiki. though that would be the best place for it) of current backends and the features that currently work? Perhaps even what is being worked on next?
I'm trying to decide on MP or FTR and it sounds like the latter is easier to get working without stuttering, but I can't find a list of what works in both.

Thank you

Tismon, this weekend I have created a 'feature document' for the ForTheRecord add-on for XBMC.

You can find it on the FTR forum here: http://www.4therecord.eu/forum/viewtopic...=41&t=2292.

I hope this provides some answers to your questions. Most of the 'quirky' behaviour is found in adding/deleting timers. This is because FTR is not based on simple timers, but using a rule-engine to convert schedules (than may contain many, many decision rules) to create instances of 'upcoming recordings'. Translating a simple XBMC timer into a complex FTR schedule leaves ample room for mismatches.... although most of the time this works much better then I ever anticipated.

Regards,
Fred

Does FTR support the Hauppauge HD-PVR ?

I can't test as I'm currently using Linux, but would consider going to windows if it does since Linux support for the hd-pvr is a bit flakey...

It does when you use MediaPortal TV Server for it's backend instead of Argus, which is what I do. I have two.

(2012-06-05 02:59)Swifty Wrote:  Does FTR support the Hauppauge HD-PVR ?

I can't test as I'm currently using Linux, but would consider going to windows if it does since Linux support for the hd-pvr is a bit flakey...

It depends on the type of your card really.

The ForTheRecord server uses it's built-in tuner Argus for digital tuner cards (DVB-S, DVB-T and DVB-C). If your card has BDA driver support, you're usually good to go (http://en.wikipedia.org/wiki/Broadcast_D...chitecture).

Analogue TV-cards are supported by the ForTheRecord server by installing the MediaPortal TV-Tuner. The server will then use that to tune and capture the stream.

There is a long thread on the FTR forum about digital cards here: http://www.4therecord.eu/forum/viewtopic.php?f=3&t=823.

Several people on the forums have mentioned they are using the hauppauge HD-PVR cards (just search for "HD PVR"). But I can't add any personal experiences since I'm using DVB-C cards (Terratec Cinergy PCI and HD Homerun Dual).

Thanks guys.

The Hauppauge HD-PVR is indeed an 'analogue' tuner - it basically takes a component video input and outputs it as H.264 encoded stream (done on the HD-PVR itself) - they are one of the few ways to get STB input (at Hi-def) into a PC.
It's a shame that Argus doesn't support it, since I've used Mediaportal before and find the TV Server part quite slow at tuning (I use satellite tuners too).

If I used FTR with MP's TV Server does that give me any benefit (if I'm solely using XBMC as a frontend) over just using the MP TV Server alone, with the Mediaportal XBMC Plugin ?

Interestingly, I notice that Hauppuage have a WMC 7 support package here - so I wonder how they some BDA driver or something?

Cheers!

I would use FTR, and add both argus and mepo tv-server to FTR, then you have best of all worlds. Run the HD-PVR on mepo server and rest on argus.

imo FTR is the more complete backend solution, excellent sceduling options, and several clients (web, imbot, ios, android, xbmc, mepo...)

Also, I don't know this for a fact, but I believe the FTR api is superior, and has potential to be a great xbmc backend, if the xbmc developers take advantage of all the posibilites. Stuff like Channel logo's automatically read from backend is so cool, I import channel logo into FTR and all my clients automatically have them, I was so surprised when I fire opp xbmc and all the channels had logo's

Fred has promised some cool stuff for FTR users in the future, you know if you start watching a recording on one client and stop it, you can continue from same spot on a different client.

also, true timeshifting is comming soon, it's the only thing I really miss in the XBMC frontend (other shortcommings I can live with for now).

(2012-06-03 23:47)Red_F Wrote:  Tismon, this weekend I have created a 'feature document' for the ForTheRecord add-on for XBMC.

You can find it on the FTR forum here: http://www.4therecord.eu/forum/viewtopic...=41&t=2292.

I hope this provides some answers to your questions. Most of the 'quirky' behaviour is found in adding/deleting timers. This is because FTR is not based on simple timers, but using a rule-engine to convert schedules (than may contain many, many decision rules) to create instances of 'upcoming recordings'. Translating a simple XBMC timer into a complex FTR schedule leaves ample room for mismatches.... although most of the time this works much better then I ever anticipated.

Regards,
Fred

That is exactly what I meant. Thank you for taking the time to compile that.
Out of curiosity simply because I haven't seen it talked about much, does the radio portion work?