Posts by M-Reimer

    Hintergrund ist die Anstehende Renovierung bei den Schwiegereltern; es stellt sich die Frage, ob "überall Ethernet" nicht ausreicht und "überall SAT-Kabel" veraltet ist.

    Wie auch immer du es machst: Mach sowohl LAN als auch (falls noch gewünscht) Koax in Leerrohre! So kannst du bei "Technikwechsel" jederzeit das Kabel noch tauschen. Wo heute noch Koax rauskommt kann dann morgen schon eine LAN-Dose sein.


    Und ganz wichtig: Nach jedem 90°-Winkel (der trotzdem mit einem gewissen Radius ausgeführt werden sollte!) kommt eine Dose ins Leerrohr um dort ggf. mechanisch nachhelfen zu können falls das Kabel doch nicht um mehrere Bögen gezogen werden kann.


    Bezüglich Sat>IP:

    • Bevor du mehrfach kaufst würde ich für eine zuverlässige Lösung auch die Server von Digital Devices mal genauer betrachten.
    • Sat>IP geht generell nicht mit HD+. Privatsender also ausschließlich in SD.
    • Es gibt mittlerweile mehrere denkbare Lösungen für IPTV. Dann könnte man sich die Schüssel gleich auch noch sparen.

    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.


    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.

    Ich verstehe den Punkt von MarkusE . Das "rec" ist ja eindeutig ein Pointer. Und wenn da in der Zwischenzeit irgendwo "delete" drauf angewendet wird, dann ist jeder weitere Zugriff potentiell ein illegaler Speicherzugriff.


    Ohne den Code komplett gelesen zu haben: Wäre es denn möglich die in der Schleife benötigten Werte (Filename, ...) einfach noch im Lock auf Variablen zu legen? Also um danach den "rec" Pointer gar nicht mehr zu brauchen?


    Seit der VDR diesen Locking-Mechanismus nutzt habe ich persönlich etwas den Überblick verloren wann das genau wie genutzt werden sollte. Vielleicht kann kls ja hier aushelfen und sagen wie man genau mit einer Schleife über Aufnahmen laufen sollte wenn innerhalb der Schleife für jeden Aufnahme potentiell irgendwas um eine Sekunde Zeit aufgewendet wird.

    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.


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

    Ein gekreuztes Aderpaar zeigen die besagten Messgeräte an.


    So doof es sich anhört, aber ich würde eine Widerstandsmessung probieren. Ein kurzes Patchkabel in der Mitte durchschneiden. Bei der einen Hälfte nun die Paare kurzschließen und verlöten (niedrigen Widerstand herstellen). Dieses Kabelstück auf die eine Seite der Leitungsstrecke. Dann mit dem anderen Kabel auf der anderen Seite jeweils den Widerstand der kurzgeschlossenen Paare messen. Die Widerstände sollten gering ausfallen (wenige Ohm) und vor allem bei allen Paaren etwa gleich sein. Ziel der Aktion: Herausfinden ob ein Paar an einer Dose nicht gut kontaktiert. Die LEDs an den einfachen Leitungsprüfern leuchten nämlich auch wenn da ein paar hundert Ohm Übergangswiderstand vorliegen.


    Und zu Cat7: Lassen! Kann mir keiner erzählen das er das in den im üblichen Wohnhaus vorliegenden Gegebenheiten so verlegt bekommt, dass die theoretisch guten Eigenschaften von Cat7 noch bestehen bleiben. Dem gegenüber steht aber das das Zeug echt fies zu verlegen ist.

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

    Nein. Das ist von dem ganzen HD+/CI+ ja auch gar nicht gewollt. Der Stream wäre dann ja unverschlüsselt.


    Es geht nur mit zertifizierten Geräten und die haben dann halt auch so nette Features wie ein Verfallsdatum der Aufnahmen und eine Blockade des Spulens während der Werbung.

    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.

    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?

    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.

    Vor vielen Jahren wurde vnsiserver vom ursprünglichen Entwickler komplett aufgegeben. Das Kodi-Plugin ging dabei direkt ans Kodi-Team wo nötige Anpassungen bei PVR-API-Änderungen behandelt werden.


    In der Zwischenzeit hat mdre  schonmal am Plugin gearbeitet. Er ist aber schon länger nicht mehr im VDR-Portal aktiv und auch sein GitHub-Account scheint relativ tot zu sein. Auf eine Anfrage wurde auf jeden Fall einen Monat lang nicht geantwortet. Auch bei seiner Ankündigung im Forum hier hatte er eigentlich eine Erweiterung um neue Features bereits ausgeschlossen. Genau zum Thema "neue Features" ist aber jetzt eine Anfrage in der vdr-projects Organisation reingekommen.


    Um für weitere Entwicklung ein "unter Kontrolle stehendes" Repo zu haben gibt es jetzt: https://github.com/vdr-projects/vdr-plugin-vnsiserver


    Ich weiß nicht ob überhaupt noch Interesse besteht den Pull-Request nochmal neu zu stellen, aber im Falle das er eingeht (was ich natürlich begrüßen würde) haben wir eigentlich einen Fall der so für die "vdr-projects-Organisation" nie geplant war. Eigentlich war ja das Ziel erstmal so "geparkte" Plugins nur am Laufen zu halten. Und ob etwas einfach nur kompiliert kann ich auch selber mit wenig Aufwand prüfen. Deshalb vorläufig folgende Regel für den Fall (muss noch ins Reine geschrieben werden bevor es auf https://vdr-projects.github.io/ kommt):


    Wenn jemand ein neues Feature für ein "Community maintained" Projekt erstellt, dann muss auch "die Community" das Feature bewerten und testen. Soll heißen wenn ein Mitglied der Organisation sich nicht im Stande fühlt das Feature zu bewerten oder zu testen, dann bleibt der Pull Request offen stehen und der Einreicher muss hier im Forum "für sein Feature werben" und um Tests bitten. Nach einer Diskussion hier (mit positivem Feedback) ist dann auch das Akzeptieren des Pull-Requests möglich.