Artwork and backend resume support / Testers needed

    I've made version of VDR vnsiserver and Kodi VNSI client which supports movie and tv series artwork and backend resumepoints.


    As M-Reimer wrote here https://github.com/vdr-project…1#issuecomment-1114184774 I need testers for this so we can be sure that everything works.


    In order to use these new features you need modified vnsiserver and Kodi client. You need to build both yourself. Also latest vdr-plugin-tvscraper is needed (available on yavdr ppa) https://github.com/MarkusEh/vdr-plugin-tvscraper

    For using backend resume enable it on Kodi vnsi client settings.


    Links:

    vnsiserver: https://github.com/Dis90/vdr-p…e/tvscraper_backendresume


    pvr.vdr.vnsi:

    Kodi Matrix: https://github.com/Dis90/pvr.v…aper_backendresume_matrix

    Kodi Nexus: https://github.com/Dis90/pvr.v…raper_backendresume_nexus

    Windows/OSX/Android builds can be found here: https://jenkins.kodi.tv/blue/organizations/jenkins/kodi-pvr%2Fpvr.vdr.vnsi/detail/PR-180/6/artifacts


    Pull requests made to https://github.com/vdr-projects/vdr-plugin-vnsiserver/pull/1 and https://github.com/kodi-pvr/pvr.vdr.vnsi/pull/180

    I think we should do all communications, around this new feature, here.


    I can not really decide if the way, how you added the new feature, is the best way to do it. But I guess the Kodi team will give you some infos about this as soon as the "VDR side" is reviewed here.


    I only have two comments after reading your code:


    Please keep this newline intact: https://github.com/vdr-project…87ed4ae610def78340d2R3520


    And about instancing the plugin link to VDR, you did here: https://github.com/vdr-project…87ed4ae610def78340d2R2735

    If you borrow the instancing from the skindesigner plugin https://gitlab.com/kamel5/skin…/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.

    Quote from M-Reimer

    Please keep this newline intact: https://github.com/vdr-project…87ed4ae610def78340d2R3520


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


    Quote from M-Reimer

    And about instancing the plugin link to VDR, you did here: https://github.com/vdr-project…87ed4ae610def78340d2R2735

    If you borrow the instancing from the skindesigner plugin https://gitlab.com/kamel5/skin…/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.

    See: https://forum.kodi.tv/showthre…35&pid=3092181#pid3092181


    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.

    Is there actually any way to get the interfaces unified again?


    At least my state is that more people are using scraper2vdr and not supporting this would probably reduce the potential user base quite a bit.


    If the new interface is better: Would it be an option to get scraper2vdr updated?

    Hi,


    The new interface provides more data, and it provides URLs to images that work on any client connected to the internet.

    > Would it be an option to get scraper2vdr updated?

    Should be possible. The question is: who volunteers?

    Other solution: just install tvscraper.


    ~ Markus

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

    Quote from MarkusE

    Why not?

    "scraper2vdr" fetches the meta data from the "global epgd MySQL database" while tvscraper fetches indivudually on each client. Probably works but I still think epgd users will prefer scraper2vdr to utilize their global database better.


    Would be way better if we managed to get a unified API again. But in the end I won't use either so just my two cents.

    -Dis I think you checked other implementations to learn some backgrounds? I'm wondering how other PVR backends have solved this.


    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.

    • If I already have the files cached on the server I may also want to profit from that. For example to keep as much as possible up and running in case of internet downtime for whatever reason
    • For some grabbers the use for PVR backends is at least "against the TOS" and caching stuff would at least put some stress from their servers
    • Data providers are coming and going. For example epgdata is "going" soon. And it is not that uncommon that websites use Referrer based deep link protection on images. It may even be possible that images can only be downloaded if the login cookie is set. With a server side cache this can all be handled by the data grabber, but if you want to send deep links to Kodi then this either fails in this case or hacks on the Kodi side are needed

    At least the last point is kind of critical in my opinion. I'm author of an Referrer blocker Add-on for Firefox and so I know that silly Referrer based content protection is all over the internet. And also the "you have to be logged in to access this link" seems to be far from impossible given that some data providers require you to have an account.


    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.


    And as a nice side effect this maybe also allows to get scraper2vdr compatible as a bonus.

    Quote from M-Reimer

    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.


    Quote from M-Reimer

    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.

    Quote from M-Reimer

    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 (https://github.com/kodi-pvr/pv…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 https://github.com/b-jesch/script.module.pvr.artwork but this needs skin which has support for it.

    Quote from -Dis

    At least Nextpvr provides own url's for images (https://github.com/kodi-pvr/pv…9/src/Recordings.cpp#L377)

    Now it would be actually interesting how the final URL looks like. Kodi can use "special URLs" internally for nearly everything. And I guess what nextpvr is doing here is using this feature to transport the actual image data over their own protocol.


    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.


    Quote from -Dis

    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?

    I can only guess and as the protocols were compatible between tvscraper and scraper2vdr, I think they also use local image paths. But I understand the point. Both "scraper plugins" were planned for being used by the same VDR that loaded the plugin. But we have to somehow get the image to the connected Kodi client.


    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".

    Quote from M-Reimer

    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 :(


    Quote from M-Reimer

    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.

    Just my 2 cents:

    Eventually one can download the images ONCE on VDR and share them with Kodi via network share?

    So that Kodi (or the Kodi-Plugin) sees "local" URLs to the local network share (from VDR or a NAS).

    MyVDR: yaVDR-Ansible (Ubuntu 20) - softhddevice-openglosd (ffmpeg 2.8) - epgd/epg2vdr - skindesigner estuary4vdr (adaptiert) - 1920x1080@50 Hz | kodi 18 - inputstream + amazon vod
    Aerocube M40 | 300W | ASRock H61M-GE | Intel G530 | Asus ENGT520 | 2 x TT-budget S2-3200 | ASRock Smart Remote (CIR) | 4 GB RAM | 120 GB SSD | 3 TB HDD

    Do you mean like changing tvscraper conf to point cache folder in smb share so paths that tvscraper provides are then pointed to network share? That can be one option but does same paths work on Windows, Mac and Linux? I'm just thinking does Kodi need smb://

    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:

    Code
    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.

    Hi,


    I don't know about other pvr plugins, but KODI itself uses internet URLs for images:

    During scraping, KODI does not download any images, but only writes the URLs to it's database:

    sqlite3 MyVideos119.db

    select * from art where media_type <> "actor" limit 10;


    I see several advantages, for example faster scraping, and less traffic on the internet databases during scraping. Also, this approach is supported by the internet databases: No API key is required to download the images.

    There are also disadvantages, of course.


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


    ~ Markus

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

    Quote from MarkusE

    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.

    Quote from MarkusE

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

    Actually if Kodi does the same it should be OK. If this ever gets problematic, then Kodi has to fix on their side, first.

    And to be honest I somehow mixed up "EPG data providers" with "Movie metadata providers". While the EPG data providers sometimes need a login (epgdata did) the movie databases are meant to be used for "fetching movie info" and (so far) don't need any login.


    Quote from -Dis

    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.

    I guess the better way would be to get scraper2vdr updated to also provide URLs. Most users, with Kodi clients, have their VDR as some kind of "central server". So VDR and Kodi on the same machine does not make that much sense.

    Having proper scraper2vdr could potentially also make the audience for testing the changes a bit bigger (but it may also be that we see the usual "summer low" here which happens every year).

    I'm completely unsure about the maintenance state of scraper2vdr. If there was an active maintainer, maybe he could help with getting the interface added...


    Edit: And if scraper2vdr is still maintained, then the coordination with its maintainer should happen before going any further with the goal to somehow agree on one unified interface again.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login