XBMC 12 (Frodo) - So What's The Plan?
#31
(2012-04-23, 10:53)da-anda Wrote: 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.

Why would a recordung require to switch channels? When the recorded show starts, the backend switches channels and starts to record but you can still view the rest of the timeshifted data to the end where the tuner switches channel.

No matter whether the buffer continues: The timeshifted program stoppes at the point he switches to the other channel in live tv... nothing enlse happends when you record.
Reply
#32
if the backend is intelligent enough I'm fine with it - but if backend flushes TS buffer while switching to the recording-channel like I understood Margro, then this would be a no-go.
Reply
#33
Better differentiate Live-Buffer from time shift , which are 2 different things i strongly believe.

VDR does: LiveTV -> <press pause> -> create a recording and instantly play it. Or you can step into ongoing recordings.

Having something like that would indeed be nice. Plus:
EPG sync improvements (performance !) or rather request the necessary information from backend at the time needed.
showing current/next instead of playback progress indication (make it appear as live tv not playback of a stream).

+ getting the vdr pvr addon inside the project again.
Reply
#34
steffen_b - well, many PVR backends support permanent timeshift - so regardless if you pressed pause or not, you can jump back to the end of the buffer. This is (IMO) the best way of how a timeshift buffer should work. OnDemand timeshift like you discribed is kinda "poor mans timeshift" Smile - but ofc. also reasonable.
Reply
#35
I have about 10 years experience (as a user) with PVR HTPC, starting with MythTV about 10 years ago, changing to MediaPortal in 2005, testing For The Record several times since 2008 in combination with Mediaportal. I started looking at XBMC when there was reports of PVR development in 2010. I made the change to XBMC frontend with For The Record + Argus backend this year.

First thing that comes to mind about XBMC is "we do everything ourself, and all is done inside the frontend", very userfriendly, but also limiting, fortunatly you have the advanced option of digging into config files.

For the sake of PVR development I think you have to let that go of the done inhouse approach, PVR has to be an "outside" job. There are some great backends out there that does an excellent job, some are more advanced than others, some are easier to setup than others. XBMC PVR capability should be limited by the options of the backend, not the other way around.

I'm a big fan of FTR (argus), it's not an easy task to setup (from xbmc pov), but not bad compared to several other backends. FTR is based around EPG and scheduling, with very advanced options available, you will never miss your favorite show again, FTR does all a PVR needs to do, but it's a "server" type of program, it has managment console to handle all the advanced options. What it lacks is a frontend GUI that take advantage of it's great potential (well you do have webinterface, android app, IM-BOT etc). This is where XBMC comes inn, I hope....

The current PVR implementation of XBMC suffer from it's "we have to do everything ourself, inhouse" approach. It has a set hardcoded base of functions and the PVR backends are limited by those, rather than XBMC setting the limitations, the PVR backend plugin should set those. Like why does XBMC have it's own EPG database, channel manager, scheduling options etc ? This is the job of backend. Right now I have FTR filling a database with EPG data, then this is imported into XBMC's own database, doesn't make sense.

IMO XBMC should not focus on creating pvr functions inhouse (like timeshifting etc), this is the job for backend, if your backend doesn't support it, though luck, get a better backend or live without it. XBMC focus should be to have the GUI available to take advantage off all the options backends provide, then it's up to pvr plugins to choose what gui opptions to support.

I may be way off here, I'm not a programmer.

With Marcels latest PVR build and FTR(argus) backend I got a setup working fairly nice, I got excellent backend options available via web and phone app, and live-tv works pretty nice. Currently there are a few tings that is frustrating (and I was used to from mediaportal and mythfrontend)

1. I have yet to find out how to sort channels, seems like a big battle between xbmc and the backend, I have it sorted perfectly at both ends, but when you connect them it gets messed up and all channels are sortet by alphabet.

2. Timeshifting, I already have this in the backend, and I can pause live-tv, but I cannot fastforward or go back to see that goal one more time.

3. Remote control, this is not really limited to PVR but XBMC in general. IMO the remote option of xbmc is really messed up, so many times you need 2 buttons for one function, and different skins handle buttons differntly. The most frustrating being backspace and escape, 2 buttons for 1 function, sometimes you have to hit backspace to go back one step, other times you have to use Esc...
Reply
#36
kra77 - I think the "inhouse" solution was chosen in order to support multiple backends at once - and supporting multiple backends requires a own EPG/Channel-Mapping db.

1) bouqets are not supported yet - so that's probably why your channels get mixed up. If you only use one backend, there's a option to use the order of the backend (will use the all-channels order of 4tr)
2) timeshift is not yet implemented. You can pause and use a limited buffer atm, but that's about it.
3) you can change this using a custom keymap - but backspace should actually go back to the previous window
Reply
#37
Like I said I'm no programmer so I don't know, I just don't get why it couldn't just read the channels and epg from the backend directly, it doesn't make sense to me to do the same job 2 times, like it doesn't make sense to do timeshifting on the frontend, when you do it on backend all clients can use it. I'm a big fan of the frontend/backend solution, so much better with multible clients. My dream would for xbmc to have a backend for everything with thin clients that could connect to it and all be in sync or a master/slave solution. Right now I import epg to several clients, run scrapers on several clients, watched status has to be set manual on all clients etc... I looked into creating a central mysql database for xbmc, but seemed like a painstaking job setting up.

I tried the option to use order of backend, doesn't work for me.

as for back, usually they do the same thing, but some places they don't and some places one of them doesn't work.
Like in refocus skin, if I click live-tv only one of the buttons will take me back, the other does nothing but provide sound.
If I enter tv-series, one back button will take me to home, other will take me to video submenu, doing the same in confluence both buttons will take me to home menu, different skin different behavior. That is frustrating. Also the keybinds on windows in xbmcbuntu is different Sad
Reply
#38
AFAIK XBMC will support both kinds of timeshift - so backend side (if only one backend is used and the backend supports timeshift) and client side (if more then one backend is used or backend doesn't have timeshift support).

XBMC is reading channels and EPG directly from the backend, it only caches it locally Wink And I could imagine that it would simply make the overall code way to complex to support both kinds in parallel (uncached read if only one backend is used, and cached if multiple). I think if the channel/EPG sync would be a bit faster and run invisible in the background (or import stuff while on splash screen so that everything is ready when the GUI shows up) it wouldn't be much different then f.e. in MP.

And don't forget that PVR support is nothing "official" yet - it's still in development and things are subject to change. And thanks for your suggestions.
Reply
#39
I just think the right way would be for xbmc to provide the gui option, and let the backend and plugin do all the work. Imho I think that would provide a better/more advanced pvr and less time coding. I dont think xbmc team should waste time coding funcionality the backend should provide. But I dont know if its even possible.

What worry me is I dont think the gui of pvr hasn't changed since I first looked at it a couple of years ago, a lot has happened behind since then, and things are starting to work really nice, kudos to everyone involved! Its just from the outside it looks like its not beeing worked on.

Btw, for your question, both argus and mepo support recording several channels on same transponder just limited by your cam if not fta. I did a test yesterday with argus and my fairly old pc could handle 2 hd channels and 2 sd channels at same time with softcam.
Reply
#40
(2012-05-08, 14:04)KRA77 Wrote: What worry me is I dont think the gui of pvr hasn't changed since I first looked at it a couple of years ago, a lot has happened behind since then, and things are starting to work really nice, kudos to everyone involved! Its just from the outside it looks like its not beeing worked on.

well the GUI is a skin issue.... since PVR isn't in the mainline yet, there are few skins that actually support it. Confluence does and works pretty well (I prefer the reFocus skin, so that's what I use) but most skins that support PVR have derived that support from Confluence and therefore present things in the same way. This is really testament to the work Jezz_X has done. People would rather reuse his stuff than start from scratch. The majority of skinners are not skinning for what they see as currently a niche feature, but once it's gone into the main branch, more skinners will take it up and we'll see more variety in the execution of the GUI....

.... as far as I can see the majority of the PVR work is being done under the hood - and this is right - leave the whizz-bang interface stuff for skinners to sort out down the line......
Reply
#41
Jimmer, yes from my experience when it comes to pvr, different skins are mostly just different colors and font, everything is pretty much the same. And that makes me think that xbmc-pvr really is a limited set of available gui options, but I don't know. It's just how it seems. Like from previous htpc software I've had experience with when you add a plugin, the plugin supply the functionality, the gui, and often the skin. For xbmc it seems like you have one plugin developer, and then a skin maker has to build that plugin functionality into the skin ? So you can't just find a cool plugin and install it, you have to wait for a skin maker to add it, or do it yourself ?

When I talk about gui, I say that in a broad way, not just skin, but functionality. So stuff like add a recording from EPG, you click on it, and you have the option "switch" is really just a view channel button, you have "timer" that ask you if you want to record it, and you have "ok" button that simply go back to prev view. Now the OK button doesn't make sense, like I've hinted to earlier we already have 2 keybinds for back, why another button aswell Smile

Now what I'd like is when I click "timer" I would like some more options, like pre/past recording, recording priority, series recording (with even more rules) etc... I'd like a option to add reminder to a show, so before the show starts it reminds me if I'm wathcing something else. Are you saying stuff like this is a limitation of the skin, not xbmc-pvr development ? You know the stuff that you can do with your remote, not much has happened there yet, I don't know xbmc that good yet, so I don't know if this is skin issue or xbmc development issue.
Reply
#42
(2012-05-08, 14:41)Jimmer Wrote: .... as far as I can see the majority of the PVR work is being done under the hood - and this is right - leave the whizz-bang interface stuff for skinners to sort out down the line......

Totally agree! I would rather a completely stable build.
Reply
#43
Kra77, we know about some GUI flaws in the PVR branch, but nobody is currently willing to touch it until the underlying codebase is not stable. As long as PVR is not in mainline, things/APIs are still subject to change (IIRC dushmanic needs to do another refactoring which most likely will break PVR entirely for some time). So please be patient.
Reply
#44
"Patience is a virtue, have it if you can.
Seldom found in woman,
Never in a man"

I'm a man damnit Big Grin

Actually I think stability is quite nice, and stuff is working, I just want more stuff Big Grin I started my xbmc-pvr adventure in 2010, but didn't make the final move until this year.

Timeshifting is what I miss the most, everything else I can live with, although there is lots of stuff I'd like added.

I'm also discussing over on the FTR forum like I said there, conflict managment has improvement potential, I would love for the backend and frontend to communicate when there is a conflict and give me a choice how to solve it. Like when you are watching a show, and a schedule recording is starting, currently it will just cut live-tv and start recording, the best WAF would be a popup in xbmc that asks me what to do, give me options like a)continue wathcing b) start recording c) start recording when I stop live etc...

There are lots of cool things you can do, problem is when there are 2 seperate developers (actually 3 here, xbmc,plugin and backend), you have to make them all think it's a good idea to make Big Grin

How to become best, look at your competition, take their best ideas and improve them.
Reply
#45
we all miss timeshift, but until the planned refactoring of dushmaniac is not finished, nobody is touching it. And believe me - I'm nagging dushmaniac quite often with timeshift because I really really want to get rid of MediaPortal and do a final switch to a XBMC only HTPC Wink
Reply

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