VNSI and timeshifting from recordings ?
#1
Just installed on my gentoo VDR2.0.4 and latest XBMC/VNSI:
media-tv/xbmc-9999
media-plugins/xbmc-addon-pvr-9999
media-plugins/vdr-vnsiserver-9999 (VDR plugin: VNSI Streamserver Plugin (Odenkamp branch)

Timeshifting from live TV works fine, but my typical time-shift use case is that i arrive 10 minutes too late for a movie that's being recorded with VDR, and i want to watch the recording. With the above setup, i still see the same misbehavior that i had since day 1:

Lets say i am 10 minutes late for a TV-recording. I start playing back the recording... and playback will stop after 10 minutes. I guess XBMC/VNSI seems to look up the file size/length at the start of playback and then only seek up to that end. So it's really impossible to watch a recording shortly after it started.

Is there a mistake on my side ? Then i'd love to learn what i should do to fix this.

If this is a limitation of XBMC/VNSI: Is this going to be fixed, and if so when (in Gotham ?)

If this is a limitation VNSI: Does this work with XVDR then ?

Thanks!
Reply
#2
You have to start the channel which is recording, not the recording.
Reply
#3
Checking... Ok, i see.. quite confusing:

a) It would really be nice if it was possible to simply play recordings that are ongoing. Any chance that this could be added to the features of vnsi/xbmc ? Thats really one of the features that makes the VDR GUI so user friendly, and unless the same is possible with XBMC/PVR, its really hard to get the WAF up with XBMC.

b) If i channel zap through "live tv", and i encounter a channel that is recording, it starts to play back from the start of the recording. Thats quite illogical when zapping channels. It should start at the current time.

c) Maybe it's a problem of my mcd remote, but i don't seem to have any key to jump directly to the end of the recording either. Is therer an XBMC function i should look for that i could map to a key ?

d) Are there any keys to jump forward/backward ? I've only found FF/FR keys and they're quite cumbersome. Even more so, when doing FF it's not even "stopping" at "live", but continues on forever until the user explicitly presses "play". Quite unintuitive.

e) When pressing "OK", the GUI comes up (confluence), but the GUI shows only a bar indicating how far into the current programming one is. It does not show where the recording buffer starts and stops. That would be extremely helpful to have (sorry, been used to that GUI from Tivo since 2000 ;-)

Thanks a lot!
Reply
#4
Improvements require lots of changes to XBMC PVR, i.e. VNSI reports buffer times but skins don't use this information yet. The next iteration (Gotham +1) will bring further improvements.
Reply
#5
Sure about the improvements. But wrt to the other issues i mentioned, I tried XVDR:

-> When zapping live channels and getting to a channel being recorded, one is taken directly to the live location of the channel - as opposed to the starting time of the recording as VNSI does for me.

-> When playing back a recording that is still ongoing, the playback nicely continues and does not stop at the initial recorded end-time as VNSI does for me.

What really is the intended behavior of VNSI in these cases ? Is what i am observing with VNSI a feature or a bug ?

P.S.: Can't use XVDR because it's not running stable. I see VDR crashing, and after crashing it does not come up but goes into boot loop. And when its running it causes playback to become jumpy when enabling full timeshifting *sigh*.
Reply
#6
Currently it works as designed. The average system has only a single tuner, hence zapping while recording is a use case not that important for the majority of users. Using the system while recording in most cases means that a user want to watch a recording in progress.

I can enable it via the recordings view as well though not sure how ffmpeg behaves when seeking beyond initial size.
Reply
#7
Wrt to ffmpeg: No idea, but xvdr does it. Maybe just update filesize every 30 seconds ?

Btw: whats the best way to jump forward/backward in a live recording ? usually, cursor left/right jump backeard/forward 30 seconds, but during TV playback its just selecting a subset of channels. Is this just a GUI issue and the +- 30 second jumps are available, or is this a limitation of VNS and/or XBMC/PVR code ?
Reply
#8
you can map the buttons in pvr section to the same functions used for normal playback.

here is something to try: https://github.com/FernetMenta/xbmc-pvr-...mits/vnsi5
Reply
#9
*FCK*ing tooling:

I am on gentoo, and the ebuild for vnsiserver uses git://github.com/opdenkamp/xbmc-pvr-addons.git, so i tried to figure out how to manually patch your changes into the emerged packet, but i gave up, because i couldn't figure out how to make it re-compile.

I then created another ebuild with your GIT, but your version fails to compile because it does not have the VDR-2.1 API changes in it. Eg:

vnsiclient.c:1277:39: Fehler: »VideoDiskSpace« wurde in diesem Gültigkeitsbereich nicht definiert

Aka: a range of objects that where just variables in the 2.0 API got changed to functions, eg.: have to be changed.

Maybe you can inherit the fixes from Odenkamp branch into your branch to be compileable under the 2.1 dev version of VDR ?
Reply
#10
You most likely took the wrong branch of my repo. My master branch is not maintained, you have to use vnsi5 branch which is opdenkamp master + the changes mentioned.
Reply
#11
Indeed. Compiled it first with obdenkamp branch where the fix created some strange results, eg: whenever playback reached the previous file end, it would re-set and start over from the beginning.

Compiling with your actual vnsi5 branch seems to produce pretty good results:
1. In general it seems to work. Will be using it more.
2. When trying to jump to the end of the current recording, results are mixed:
a) Sometimes i get the desired result (which is what VDR has as well), which is that it will not stop playback and repeated clicking on jump-forward just stays pretty much on the end and then continues to play.
b) Sometimes i get into playback stopping.
c) Sometime i get into a playback that produces broken frames in an ongoing fashion.

This is consistent whether i go through recordings via live-tv, or the recordings:: folder in video.

In VDR, it is not possible to jump forward beyond ~30 seconds into the (current) end of the recording, so whether a file is still recording or finished, jump-forwarding will never cause finish of playback. Fast-Forward does actually fast-forward to the end and then stops. I like this behavior very much, and i bet problem 2.b)/2.c) would be solved if XBMC could get the same semantic as well. But i guess thats not plugin code, but basic XBMC code ?

So, thanks a lot so far. Definitely makes VNSI a lot more useful to me!

Btw: with playback from recording working now, how about the channel changing to a currently recorded channel ? any chance to change this such that playback will be from current live time as opposed to beginning of recording ?
Reply
#12
Quote: how about the channel changing to a currently recorded channel ? any chance to change this such that playback will be from current live time as opposed to beginning of recording ?

The majority of systems are single tuner and the main use case for switching on a system which is currently recording is to watch this recording.

As I said earlier there are some important features missing in XBMC: show current buffer positions for timeshift, playing time, etc. Maybe we can implement a navigation function for moving to live position but this is for Gotham+1.
Reply
#13
I guess i am just irritated by the behavior of VNSI to go to the beginning of the recording because it is a) difficult to get to the live position because the key-bindings are such that there is no key to do it, and b) i have not seen any other DVR that has this behavior, all the ones i have seen (including TIVO that i use since 2000) will zap to the current playing location.

In a volunteer project, the priorities are always defined by the folks spending their free time, so i won't argue on priorities with you, but just continue to appreciate the good work you're doing ;-)) I definitely would love to see better visual representation of the VNSI capabilities in the GUI.
Reply
#14
The behaviour irritates me as well:

if all vdr's devices are occupied by recording(s) - vdr can only switch to channels on the same transponder as the recording(s) are on - switching to a channel currently recording should be no problem at all - switching to other channels might be.

Conclusion:
- Switching should work just like "normal"
- Starting playback should start the recording from the beginning and must not end at the length of the recording at the time of the start of the playback

and yes:
(2014-01-20, 09:20)te36 Wrote: In a volunteer project, the priorities are always defined by the folks spending their free time, so i won't argue on priorities with you, but just continue to appreciate the good work you're doing ;-)) I definitely would love to see better visual representation of the VNSI capabilities in the GUI.
kodi3: LE 7.93.5 on Pi3
kodi4: LE 7.93.5 on Wetek Play 2
Server vdr 2.2.0, vnsi,...
Reply
#15
I would like to +1 that, recordings for me are recordings if I turn on LiveTV I expect it to be live. That is not meant negative regarding all the effort going into this project of course just the way I tend to use my TV.
Reply

Logout Mark Read Team Forum Stats Members Help
VNSI and timeshifting from recordings ?0