[bluenote]

Thanks for the education krusty.
It sounds like the simple addon non pvr interface would actually be useful in some cases. I wonder if there might be a case for having the wmc addon in two parts?
I'm sure it would have cons, but if you had the ability to launch it from within wmc... ?

[scarecrow420]

Regarding the using a current recording file rather than live channel...

If you are already recording something and select it from the channel or timeline, chances are its something you want to see from the beginning anyway. That should simplify the approach rather than offsetting it to current time and having the user rewind.. I can see how once the show is over, the timer has turned off recording and the next show is not time shifted or even active for that matter. I know Windows Media Center handles this gracefully. Perhaps their approach is also exposed in the .dll, to handle just such an occurrence post timed recording? Even if there was no way to do it, just being able to watch a currently recording item from the channel list/EPG is a win even if it stops at the end!

ah see well here already we have some mixed requirements. I thought you were saying if a channel was already being recorded and you chose to watch that channel live, to avoid tying up a 2nd tuner we should access the stream being used for the recording. In this use case, skipping ahead to the current time index would seem to be the requirement since you dont want to watch that recording per se, you actually just want to watch that channel live and a recording happens to already be using a tuner on that channel. Particularly in a multi client household one person could be recording Big Bang Theory while another just wants to watch that channel live and catch the end of the episode (or possibly even unaware/uncaring that someone else is recording that show).

But you've now mentioned a second use case which is more along the lines of making it more convenient to see an in progress recording and start watching that recording (from the beginning) by clicking on the EPG entry rather than having to go to the recordings section.

So it would seem at a minimum that clicking on an EPG entry/channel that is currently having a recording in progress should maybe ask whether you want to watch from the beginning or from now...

I find XBMC's compartmentalization of LiveTV confusing at best. I understand their motives to decouple from that main logic but I just don't get the implementation. It seems for a pvr plugin to be successful in their model it must also be installed in conjunction with a custom skin, but then the pvr plugin would be making arbitrary decisions about all the other media paths.. and that violates the compartmentalization idea all over again. It seems that a pvr plugin should be responsible for only the livetv/epg skin, within whatever skin is active, inherit the global theme, and be provided some basic RTC callback functions from the core through an api. I hope that was the future strategy for initially decoupling. I was hoping Gotham would provide some initial insight but that doesn't seem to be the case. I am happy with the reduction in CPU - makes playback much smoother.

i agree the ball does seem to be moving forward quite slowly but the idea is that XBMC interface will support/define how PVR functionality should work, and the addons/backends then provide that. We shouldnt have to have custom dialogs/skins and perhaps in the future we wont need to... for example series recording is a common feature so XBMC could/should implement support for it, then we wouldnt need to tack it on ourselves with custom dialogs that pop up after the user has already confirmed they want to do the recording. I dont think it would be workable for PVR plugins to have to control/provide the entire PVR skin, and afterall XBMC does need to have a consistent approach to say EPG, recordings, etc no matter which backend you are using... but the PVR addon interface could be further enhanced to allow more customisation/influence over XBMC behaviour. The framework is already there though, and things are still a work in progress. Eg each addon defines a capabilities matrix indicating to XBMC the things it supports and then XBMC knows to call for them (eg supports EDL, supports lastplayedposition, supports timeshift, supports live streaming etc etc). So all the building blocks are in place and once "breaking" changes can be made to the API interfaces again (things are locked down now, to stabilise Gotham) more things will be added and enhanced im sure (just as they were for gotham).

---

Thanks for the education krusty.
It sounds like the simple addon non pvr interface would actually be useful in some cases. I wonder if there might be a case for having the wmc addon in two parts?
I'm sure it would have cons, but if you had the ability to launch it from within wmc... ?

Well im not krusty but ill take it as a compliment we also can hook into adding items to the context menu on recordings, timers, channels etc so perhaps that would be a slightly more intuitive way of presenting a "Create new wishlist recording" option.

It's an interesting idea having a separate "regular" addon in XBMC that could add additional screens/management of some of this stuff, but my python skills are pretty rusty and im not sure there is that much stuff that doesnt fit into the existing PVR framework of XBMC (wishlist recording is one of the major ones I guess)

[SoCalXMBC]

So it would seem at a minimum that clicking on an EPG entry/channel that is currently having a recording in progress should maybe ask whether you want to watch from the beginning or from now...

Yes, that seems acceptable, especially in a single tuner household (most common), or if no tuner is free!

However, In a multi tuner household where a tuner is free, your dialog brings up an interesting problem. Start from the begging of the recording in progress, continue watching the recording in progress, or allow a second recording as live tv which continues on after the show using the free tuner.

This is something SageTV handled natively without any dialogs at all, it would just tune to the current recording in progress and automatically start timeshifting the show after if the display was active with the show immediately prior, and do it with only one tuner. At the time is was a very cutting edge experience, however, most DVR solutions now offer this capability.

[krustyreturns]

Thanks for the education krusty.
It sounds like the simple addon non pvr interface would actually be useful in some cases. I wonder if there might be a case for having the wmc addon in two parts?
I'm sure it would have cons, but if you had the ability to launch it from within wmc... ?

Edited - I see scarecrow covered the context menu stuff

I can't recall where the custom menu choices show up in the interface but conceivably these could be used to do custom dialogs like setup wishlists. I assume there will be the usual caveat with any custom stuff, you'll need to get your skin designer of choice to make it look nice in whatever skin you are using, we would just provide confluence. This might be interesting to try...

[bluenote]

Well im not krusty but ill take it as a compliment

Sorry small text on phone.

[scarecrow420]

So it would seem at a minimum that clicking on an EPG entry/channel that is currently having a recording in progress should maybe ask whether you want to watch from the beginning or from now...

Yes, that seems acceptable, especially in a single tuner household (most common), or if no tuner is free!

However, In a multi tuner household where a tuner is free, your dialog brings up an interesting problem. Start from the begging of the recording in progress, continue watching the recording in progress, or allow a second recording as live tv which continues on after the show using the free tuner.

This is something SageTV handled natively without any dialogs at all, it would just tune to the current recording in progress and automatically start timeshifting the show after if the display was active with the show immediately prior, and do it with only one tuner. At the time is was a very cutting edge experience, however, most DVR solutions now offer this capability.

this sort of thing is hard for us to do because we are dealing with files produced by WMC and not the actual raw tuner streams. In theory we could remux a new video stream into an existing LiveTV ts file that XBMC is playing but there are various complications right off the top of my head like when the recording ends we need to start live streaming (recording) that channel again so we have data to show when the viewer reaches the end of recording and seamlessly inject that into the liveTV ts file at the right moment plus what if the recording was paused for 3 hours, is the viewer still meant to be able to see all the timeshifted video that occured after the recording finished and the current real time, or just jump t the channel in question at real time, once they finish watching the recording? I think it's all too complex for now, and something that really has to be done by a backend/PVR system that iswritten from the ground up rather than this particular implementation which is esxternally driving WMC as a means to access a wide range of tuner hardware and worldwide broadcast standards etc without having to write any native code to interface with all of that stuff

[SoCalXMBC]

Kind of related to the discussion above with watching a recording stream in progress... If a XBMC client has tuned a LiveTV channel in one room... is ti possible to allow a second XBMC client to piggyback the same stream from a different room?

[LSU Jonno]

yes. two TV's tuned to the same live TV station share one stream...Awesome feature by the way.

This is probably tied into the past discussion which I didn't read all of but if you tune to a station that is already being recorded you'll use a second tuner by default. If you want to "share" that stream you need to open up your recordings list and play from there.

[scarecrow420]

Yes we already support that feature but it has been a bit unreliable so we have some more changes in this area next build.

Answer me this: as a user is it more important to you that the 2nd client doesn't tie up an additional tuner if watching the same channel or that additionally the 2nd client has access to the existing timeshift buffer?

The tweak we made for next build is more reliable and still has multiple clients sharing that 1 tuner but they have their own timeshift (remuxed TS file) so the 2nd client would not be able to go back in time. The original way actually pointed all clients at the 1 TS file and attempted to have the 2nd+ clients "skip" to the current live point but this has been found to be unreliable (sometimes the skip doesn't happen and the client starts from the point the first client started). It will be configurable whether to use old or new mechanism.

Thoughts?

[LSU Jonno]

I like the new method. Before I knew how y'all were doing this I was really freaked out when I'd turn to the same channel on another machine and be transported back in time an hour.

I had no hopes of being able to go back in time on that second machine. I'm glad the bug is fixed, although ever since I switched to linux clients I haven't seen the bug anymore.

[scarecrow420]

Well that's good that you dont have any expectation of accessing the existing timeshift buffer and are more concerned about streamlining tuner usage. The new mechanism does mean that the remuxer is now producing one TS file per client watching that channel which does have implications in terms of more disk space (temporarily) and also more disk writes. Not a big problem for 2 or 3 clients, but clearly it wont scale to heaps of clients, whereas the previous way (1 file shared by clients) was possibly more likely to scale. Not a big deal for most people's usage I dont think. On the backburner i still want to sus out why XBMC wasnt reliably skipping to the file position I was telling it to...

[LSU Jonno]

Yeah, the old method seems to be a little more computer friendly. If the bug can get worked out going back to the old method probably makes sense. I don't think I'd use the "feature" that would enable me to go back in time on the second machine but I'd appreciate the efficiency.

[denz]

I am not sure if this is covered. I subscribe to pay tv channels and I use anysee tuner to decrypt the channels and the issue that I am having is if I watch a channel on the main htpc and I try to watch it on my pi or any other xbmc client I get All tuners are busy for that channel.

If I stop live tv on main htpc I can watch the same channel on multiple xbmc clients it is a single tuner device. If I then go to the main htpc and try to watch the same channel it tunes to that channel and now all the xbmc clients and htpc are tuned to the same channel. So it seems to work one way but not the other. This is not a major issue but it would be great if it is possible.


2014/03/17 07:27:56.980 OpenLiveStream> -----------------start------------------------
2014/03/17 07:27:56.980 OpenLiveStream> client: Pag requesting live stream
2014/03/17 07:27:56.980 StreamProc> live-tv started
2014/03/17 07:27:56.980 SetChannel> Tuner: anysee BDA Digital Tuner(DVB-S2) / 7c1fc91b-56df-447a-b0ce-5e3db8c1d017
2014/03/17 07:27:56.980 SetChannel> > Digital: True
2014/03/17 07:27:56.980 SetChannel> > Encrypted: False
2014/03/17 07:27:56.980 SetChannel> > RecorderInfo found: True
2014/03/17 07:27:56.990 SetChannel > busy: True, client: playback\recorderbroker&EHShell.exe&6412
2014/03/17 07:27:56.990 StreamProc> process start error: No tuner available calling Close()
2014/03/17 07:27:56.990 StreamProc::Close> remuxer thread was not running
2014/03/17 07:27:56.990 StreamProc::Close> wtv was not running
2014/03/17 07:27:56.990 StreamProc::Close> closed in 0.00 sec
2014/03/17 07:27:56.990 OpenLiveStream> error: No tuner available
2014/03/17 07:27:56.990 Finished request OpenLiveStream in 0.01s
2014/03/17 07:28:46.706 MainWindow::Window_Loaded> not running as service, checking folder status.
2014/03/17 07:28:46.706 MainWindow::Window_Loaded> Done

[krustyreturns]

According to this snippet of the log, wmc is running a live stream of the channel, not xbmc. This tuner client means wmc: playback\recorderbroker&EHShell.exe&6412

Swmc can't share stream with wmc, only with xbmc. Can you not watch the channel with xbmc on your main htpc?

[denz]

According to this snippet of the log, wmc is running a live stream of the channel, not xbmc. This tuner client means wmc: playback\recorderbroker&EHShell.exe&6412

Swmc can't share stream with wmc, only with xbmc. Can you not watch the channel with xbmc on your main htpc?

It works that way unfortunately my family won't let me run XBMC on that PC I tried it and they were happy with some of the things that XBMC can do but the slow channel change was the deal breaker. It is just too slow when you compare it to WMC so until that gets fixed it is a no go zone.