Posts by -Dis

Quote from M-Reimer

I don't think so. All VDR has is a "resume" file which is placed next to the other recording files: http://www.vdr-wiki.de/wiki/index.php/Resume

It stores a frame number and only one per recording.

According to that wiki page (Google translated):

Quote

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.

github.com

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

Quote from M-Reimer

After a first look at the code: You take the file path from tvscraper (or scraper2vdr) first.

If "live" exists, then you replace this file path with the URL reported by live.

Does this mean that on a "single user only" system (VDR and Kodi on the same machine), Kodi could directly access the files on the local drive in this case?

So on an "all on one machine" the live plugin is not required and for network clients the live plugin can be used (and most people will probably use it anyway as a browser based interface to manage stuff on the server).

Display More

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?

Quote from M-Reimer

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

Quote from M-Reimer

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 https://github.com/MarkusEh/vdr-plugin-live
cd vdr-plugin-live
make
make install

Install vdr-plugin-tvscraper example from this PPA https://launchpad.net/~seahawk…+archive/ubuntu/vdr-2.6.3

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

vdr-plugin-vnsiserver

git clone https://github.com/Dis90/vdr-plugin-vnsiserver -b tvscraper_backendresume
cd vdr-plugin-vnsiserver
make
make install

Kodi add-on if your Kodi is installed on Windows/Mac/Android/iOS you can get from here: https://jenkins.kodi.tv/blue/organizations/jenkins/kodi-pvr%2Fpvr.vdr.vnsi/detail/PR-180/6/artifacts

Build instructions:

mkdir kodi_vnsi
cd kodi_vnsi
git clone https://github.com/xbmc/xbmc -b Nexus
git clone https://github.com/Dis90/pvr.vdr.vnsi -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
make

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.

Got it working, thanks. There should be mention somewhere that server url means url without port number Although makes sense after reading help and seeing example url.

I updated Github repos. VNSI client for Kodi 19 Matrix is not yet updated.

Thanks for this but can you provide example how to call this new service. I'm just too rookie in C

MarkusE Can you test all new features, backend resumepoints for recordings and tvscraper integration?

M-Reimer Is it enough if one person and me tests new features?

Sadly no one haven't given any feedback

Quote from MarkusE

> Is new interface ready to use?

No .

Okay, no rush

Quote from MarkusE

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

MarkusE I see you have made some changes to Live and Tvscraper. Is new interface ready to use?

Little bit off topic, have there been some change in Tvscraper which makes it not to found series or movies if name in epg event is in local language? It used to work but not anymore.

Quote from MarkusE

Someone confirms that he will update the vdr-plugin-vnsiserver pull request, to use the old scraper service interface (also supported by scraper2vdr) und the new service interface in live (which I will provide) for the vnsiserver enhancement

I can make this change if no one else volunteers and if pull request is accepted to vnsiserver.

Here's backtrace.

Can you give me instructions how to do backtrace?

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

Aug 26 15:08:29 telkka vdr: [62024] tvscraper: scraping Channel Liv HD C-0-22-12202
Aug 26 15:08:29 telkka vdr: [62024] tvscraper: scraping Channel Jim HD C-0-22-12203
Aug 26 15:08:31 telkka vdr: [62027] VNSI: Requesting clients to reload channels list
Aug 26 15:08:31 telkka vdr: [62027] VNSI: Requesting clients to reload timers
Aug 26 15:08:32 telkka vdr: [62024] tvscraper: scraping Channel Hero HD C-0-22-12204
Aug 26 15:08:33 telkka vdr: [62024] tvscraper: scraping Channel TV5 HD C-0-25-12501
Aug 26 15:08:34 telkka kernel: [  913.663888] traps: tvscraper[62024] trap divide error ip:7f3ce4848320 sp:7f3c8dffa000 error:0 in libvdr-tvscraper.so.2.6.1[7f3ce482b000+49000]
Aug 26 15:08:35 telkka yavdr-frontend[1641]: INFO:pydbus2vdr:VDR Status: stopped
Aug 26 15:08:35 telkka yavdr-frontend[1641]: DEBUG:softhddevice:g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name de.tvdr.vdr was not provided by any .>
Aug 26 15:08:35 telkka systemd[1]: vdr.service: Main process exited, code=killed, status=8/FPE
Aug 26 15:08:35 telkka systemd[1]: vdr.service: Failed with result 'signal'.
Aug 26 15:08:35 telkka systemd[1]: vdr.service: Scheduled restart job, restart counter is at 2.
Aug 26 15:08:35 telkka systemd[1]: Stopped Video Disk Recorder.

Quote from M-Reimer

I somehow hoped to get a bit more feedback.

Yeah I hoped that too Phunkyfish just recommended me to ask testers from Kodi forums (https://github.com/kodi-pvr/pvr.vdr.vnsi/pull/180). But do we need more testers for these features?

Quote from M-Reimer

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.

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.

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.

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

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.

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