Posts by -Dis

    I don't think so. All VDR has is a "resume" file which is placed next to the other recording files:

    It stores a frame number and only one per recording.

    According to that wiki page (Google translated):


    If a value greater than 0 is entered as the "Playback ID" in the OSD setup under "Playback", then resume files created after this will have this playback ID in their name (e.g. resume.1). For example, you can run vdr on several PCs and still use the same recording directory over the network.

    But yep this is only available in VDR and not possible to use with VNSI because I can't deliver id to cResumeFile

    vdr/recording.c at 8b14723e9ef4f408cfb357f6c27235cf491efd12 · vdr-projects/vdr
    Mirror of the official VDR GIT repository. Contribute to vdr-projects/vdr development by creating an account on GitHub.

    Feature is also useful if you want to see if recording is watched or not from Live plugin :)

    Yep it will get urls for images from Live plugin if Live service is found.

    If -u URL or --url=URL is not in Live start parameters then it will return same file path as given to Live service (local file path).

    Live plugin is not required when VDR and Kodi are in same device. I don't know is there some way to detect if server and client are in same device and skip Live plugin in that case. Is there even any benefits doing that? :D

    Good idea to make it possible to disable (and disable by default) the "resume point" feature. Very useful if one person has several clients but would be a bad idea in a family with one central server where everyone watches recordings on his own client.

    If I remember correctly VDR supports resume points per client. So if I implement client id's to Kodi client then it would be possible save resume points to VDR server without using same resume points for every client.

    Edit. quickly looking VDR source code it seems to be possible only if VDR itself is client :(

    And I still think that -Dis should at least co-maintain vdr-plugin-vnsiserver as probably he is the person with the deepest insight into the plugin currently.

    I can help to review PR's but I don't have much knowledge other parts of vnsiserver than those I made changes (EPG and recording listings).

    Here's instructions how to test these new features.

    Get latest vdr-plugin-live

    git clone
    cd vdr-plugin-live
    make install

    Install vdr-plugin-tvscraper example from this PPA…+archive/ubuntu/vdr-2.6.3

    Set channels which you want to scrape from plugin settings on VDR.


    git clone -b tvscraper_backendresume
    cd vdr-plugin-vnsiserver
    make install

    Kodi add-on if your Kodi is installed on Windows/Mac/Android/iOS you can get from here:

    Build instructions:

    mkdir kodi_vnsi
    cd kodi_vnsi
    git clone -b Nexus
    git clone -b tvscraper_backendresume_nexus
    cd pvr.vdr.vnsi && mkdir build && cd build
    cmake -DADDONS_TO_BUILD=pvr.vdr.vnsi -DADDON_SRC_PREFIX=../.. -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=../../xbmc/addons -DPACKAGE_ZIP=1 ../../xbmc/cmake/addons

    Copy build add-on to Kodi

    cd ../../xbmc/addons/
    sudo cp -r pvr.vdr.vnsi/ /usr/lib/x86_64-linux-gnu/kodi/addons/

    Restart Kodi

    If you want to Kodi to use VDR resume point on recordings you need to enable backend resume from Kodi add-on settings.

    > Is new interface ready to use?

    No :( .

    Okay, no rush :)

    For your off topic questions, please check the Tvscraper plugin settings. You can select a language for each channel.

    Thanks. Found settings but I can't change system language or additional language to Finnish :( How I can add Finnish to available options?

    Edit. I added:

    {11, "fin", "fi-FI", "suomi"}

    to config.h and rebuild plugin and changed plugin default/system language to 11 and additional to 6. Lets see if that fixes the issue :)

    I'm getting this error to syslog and vdr restarts after that.

    I somehow hoped to get a bit more feedback.

    Yeah I hoped that too :( Phunkyfish just recommended me to ask testers from Kodi forums ( But do we need more testers for these features?

    As far as I remember testing tvscraper is just installing the plugin?

    What I can remember after installing you need to set what channels you want to scrap from plugin settings.

    If someday scraper2vdr starts to support new interface we can easily add support for it without modifications needed to Kodi VNSI plugin.

    Still, for KODI plugins, using internet URLs for images is best practice as KODI itself uses internet URLs for images.

    Thanks for confirming how Kodi plugins do this. With reference to this matter I'm not going to change anything but maybe also add support for scraper2vdr if there's demand. But with scraper2vdr artwork support would be limited to VDR and Kodi in same machine.

    M-Reimer What you think if I change code "little bit" and add support for scraper2vdr by using old interface for it.

    Something like this:

    static cPlugin *pTVScraper = cPluginManager::GetPlugin("tvscraper");
    static cPlugin *pScraper = cPluginManager::GetPlugin("scraper2vdr");
          if (pTVScraper)
          else if (pScraper)

    New interface also supports local image paths if we are going that way.

    This is also the first idea that came to my mind (without any knowledge if this is possible at all). Actually the VNSI protocol was meant to be a universal protocol to do all the communication needed to get Kodi connected with VDR. And as it does work for transporting whole video streams, I guess transmitting of small images should be possible.

    I too doesn't have knowledge but I remember reading somewhere from Kodi forums (VNSI section) that this isn't possible. And even if it is possible I don't have skills to do it :(

    And yes, it is attractive to just make Kodi do the image download. If others PVR addons would do the same, then I would say: Just keep it that way. But noone of us knows what limitations this would mean in future (Referer check, Cookie, ...) and I'm a big fan of "do it once and do it right".

    I understand your point.

    Currently I don't have any ideas how to solve this issue.

    Because after thinking a bit more, I am more and more unsure if it is a good idea to send "internet accessible" links at all.

    For my knowledge Kodi caches all images. So same image is not downloaded twice and images are downloaded only when needed example browsing epg events.

    Data providers are coming and going. For example epgdata is "going" soon.

    This is only issue when browsing recordings and you can always re-scrape them.

    If other PVR backends also don't prepare for this case (if they also send deep links to Kodi) then this may be not a that big priority but if others decided to transfer images using their own protocol, then maybe this is not the worst idea.

    At least Nextpvr provides own url's for images (…9/src/Recordings.cpp#L377)

    In best case Tvscraper would act as server for images so image url then would be something like https://server_ip/... instead of local path (/var/cache...)

    I doesn't have answer what is best method to use. If only local paths are provided to Kodi then those would not work when VDR and Kodi are in different machines. How this situation is handled in scraper2vdr?

    Samba share is one option to go. There's also some informations what are not available on older Tvscraper interface (director, writer) but in my opinion that is not critical info.

    I'm open for all ideas.

    If someone has solution for how to provide paths for images way that them work in all situations (VDR and Kodi in different machines). Then I can update vnsi to use methods compatible with scraper2vdr.

    I've been also thinking of dropping tvscraper support and only add resumepoints support to vnsi because there's this module available on Kodi but this needs skin which has support for it.

    I don't know why Github made that I and I don't know how to fix it.

    And about instancing the plugin link to VDR, you did here:…87ed4ae610def78340d2R2735

    If you borrow the instancing from the skindesigner plugin…/extensions/helpers.c#L10 , then your change also works with "scraper2vdr" which, I think, is used more often. This could also mean more audience for testing your change.

    That is what I initially did but after current maintainer of tvscraper suggested making new interface for this, it is no longer backwards compatible. This decision is mainly done to help in situations when VDR is in different machine than Kodi. New interface provides http url's for images instead of local filepaths.


    Supporting both scraper2vdr and tvscraper is still possible but makes code ugly and then we have to somehow deal situations when VDR and Kodi are in different machines.