Beiträge von kamel5

Zitat von SHF

Inzwischen bin ich aber am Überlegen, ob es überhaupt was mit dem Netzwerk/samba zu tun hat, oder ob es am Player liegt.

Wenn man lokal mit vlc eine laufende VDR-Aufnahme abspielt, wird das Ende der Aufnahme solange man noch nicht am Ende mit der Wiedergabe angekommen ist, nicht aktualisiert. Erst wenn man das beim Starten der Wiedergabe vorhandene Ende der Aufnahme erreicht hat, wird auch das Ende hochgezählt, die Wiedergabe der Aufnahme wird also dort nicht abgebrochen. vlc erkennt also, das die Aufnahme dann noch nicht zu Ende ist. Ob das über Netzwerk jetzt auch so funktioniert, habe ich nicht ausprobiert.

Grüße

kamel5

Zitat von MarkusE

probiert, hat aber nicht funktioniert .

Auch andere Apps unter aktuellen Android-Versionen haben mit dem Abspielen Probleme, vdr-manager und androvdr spielen bei mir keine Videos mehr, obwohl das früher mal problemlos ging. Das einzige was noch geht, sowohl Live-TV als auch Aufnahmen, ist streamdev direkt im Browser.

Ich weis auch nicht, ob man das überhaupt so kompliziert machen muss. Wenn ich das von der streamdev Anzeige im Browser aufrufe, geht auch nicht automatisch vlc auf. Es geht ein Dialog auf, wo man es dann abspielen kann. Unter Firefox kann dann der VLC ausgewählt werden, in Opera ein eigener Player.

Das würde doch erst eimal reichen, den im Moment kann ich es von live aus überhaupt nicht abspielen.

z.B.: Live-TV in streamdev: http://192.168.10.15:3000/S19.2E-1-1061-10352.ts

z.B.: Aufnahme in streamdev: http://192.168.10.15:3000/42:4146.rec.ts

Grüße

kamel5

Zitat von MarkusE

Ich müsste also prüfen, ob der Browser auf iOS läuft, und falls ja, "vlc-x-callback://x-callback-url/ACTION?url=http://192.168.x.xxx:3000/2304:213913720.rec.ts" als URL verwenden. Falls nein, müsste es die Playlist sein wie bisher.

Welche URL würde denn mit Android funktionieren?

Das sollte unter Android auch funktionieren.

Streamdev liefert bei mir z.B. folgendes: http://192.168.xxx.xxx:3000/40:2485.rec.ts, und das kann ich mit vlc abspielen.

Grüße

kamel5

Danke, habe ich ins git übernommen.

Grüße

kamel5

In den getesteten Skins funktioniert es auch.

Grüße

kamel5

Zitat von MarkusE

Also, ich kann hier wieder zurückrudern und die Startzeit der Aufnahme ignorieren. Es ist doch recht selten, dass 2 Aufnahmen das gleiche Event haben, aber unterschiedliche Sendungen sind.

Das würde ich als die beste Lösung ansehen.

Zitat von rüsseltier

Wäre es nicht sinnvoll für KODI und auch allgemeine Archivierungszwecke die Bilddateien in die geschnittene "mitzunehmen"?

Ich mein, wenn sie eh schon im Ursprungsordner liegen...

Das würde bedeuten, das der Core-VDR gepatcht werden müsste, hmm...

Andererseits nutzen ja nicht alle Skins diese Bilder, so das es dann immer noch Probleme gibt.

Eine Lösung im tvscraper wäre hier sicherlich die allgemeinere.

Grüße

kamel5

Zitat von MarkusE

Ich versteh es nicht. Irgendetwas habe ich übersehen .

Das Ganze ist noch weitaus "unklarer".

Das betrifft nicht nur geschnittene Aufnahmen, sondern beliebige Aufnahmen.

z.B.:

/Video/video0/Footloose/2024-03-07.21.55.43-0.rec

/Video/video0/Footloose/2024-03-20.16.02.43-0.rec

Das ist 2 mal die gleiche Aufnahme zu unterschiedlichen Zeiten. Wenn man einmal die Aufnahme ohne tvscraper und einmal mit tvscraper macht, hat nur die Aufnahme Scraperinformationen, die mit tvscraper gemacht wurde. Erst wenn die Aufnahme ohne tvscraper nachgescrapt wird, erhält sie auch Scraperinformationen. Das gleiche trifft dann auch für geschnittene Aufnahmen zu, das sind dann quasi auch Aufnahmen ohne tvscraper.

Bei einer geschnittenen Aufnahme ist die info-Datei die gleiche, wie bei der ungeschnittenen.

Ich habe dann mal das Datum und die Uhrzeit der geschnittenen Aufnahme auf das gleiche wie bei der ungeschnittenen Aufnahme gesetzt und dann gab es auch Scraperinformationen.

Die Ursache scheint also in unterschiedlichen Startzeiten zu liegen "2024-03-20.16.02.43-0.rec".

Grüße

kamel5

Zitat von Taipan

Mir ist aufgefallen, das ein geschnittener Film sehr lange ohne Bilder bleibt, obwohl das ungeschnittene Original bereits alle Bilder hatte...

Das ist mir auch schon aufgefallen, bei verschiedenen Skins. In meinen Skins nutze ich da die Services "GetPoster" und "GetPosterThumb". Scheinbar auch nicht bei "GetSeries" und "GetMovies".

Das gilt übrigens für alle Scraper-Informationen.

Soweit ich das verstanden habe, hat das auch nichts mit den Bildern im Aufnahmeverzeichnis zu tun? Wenn man die löscht, wird es bei ungeschnittenen Aufnahmen immer noch angezeigt.

Wenn ich die Aufnahmen extra scrapen lasse, dann sind die entsprechenden Daten da.

Schon seltsam.

Grüße

kamel5

Zitat von cinfo

tvguide: Setze ich tvguide.hideChannelLogos = 1 ist der Anzeigefehler (Bild im Post oben) weg. Sollte ich

in die setup.conf übernehmen

Naja, es sollte schon beides funktionieren...

Habt ihr mal den Eintrag "Use workaround for HWAccelerated OSD" auf ja gesetzt?

Das sollte Probleme mit verschiedenen Ausgabeplugins beheben.

Ansonsten mal alle Einträge von tvguide aus der setup.conf hier posten.

Grüße

kamel5

Hallo,

neue Version 0.4.3 im git:

- Make display of the device in the channel view configurable

- Add some more video window sizes in the menu

- Add timer to display replay

- Use the frame parameter of the VDR (VDR >= 2.6.5), if available, in the display replay

- New config option: Display video properties from info file (if available)

- Rework of cDrawDescription in the display menu

Grüße

kamel5

Hallo,

es gibt nach langer Zeit mal wieder eine neue Version 2.0.12:

- Revert "Fix for some skins"

- Add error sign to recordings list

- Optimize myMenuRecordings::Title()

- Fixed an unnecessary double display of menu items in the Recordings menu

- Added frame parameters (VDR >= 2.6.5) to the detailview

- Number of errors for error sign is now configureable

Grüße

kamel5

Zitat von gggggg

Ich hab den Skindesigner am laufen und dachte skinsimple nutz den auch. Jedenfalls meldet tvguideng trotzdem, dass die Skinsimple nicht unterstützt wird ...

skinsimple, LCARS, skinnopacity und auch andere Skins sind native Skins, die nichts mit dem skindesigner zu tun haben.

Dafür ist tvguide (ohne "ng").

Wenn man tvguideng benutzen will, muss man einen skindesigner-Skin auswählen und hoffen, das es für diesen Skin eine passende xml-Datei gibt, sonst geht tvguideng auch nicht mit dem skindesigner.

Wenn Du also keinen skindesigner-Skin nutzt, kannst Du auch nicht tvguideng benutzen.

Und noch was, tvguideng ist durch das angehängte "ng" nicht automatisch neuer, hat eher weniger Funktionen als tvguide.

Aktuell ist momentan tvguide-1.3.8.

Zitat von gggggg

das sieht so aus:

Das könnte ein Problem mit dem Ausgabe-Plugin sein. Probiere mal, ob es hilft, unter "Allgemeine Einstellungen" vom Plugin tvguide, den Eintrag "Use workaround for HWAccelerated OSD" auf ja zu setzen.

Ich nutze tvguide hier auch intensiv. Bei mir tritt dieses Problem nicht auf. Ich hätte da im Moment auch keine weitere Idee dazu.

Grüße

kamel5

Zitat von gggggg

tvguideng läuft ja leider nicht mit LCARS u Skinsimple.

Das kann damit nicht funktionieren, da das nur für den skindesigner als Skin ist.

Zitat von gggggg

wird das überhaupt noch gepflegt ?

natürlich.

Zitat von gggggg

(schreibt ORF2 E in die Progammbalken rein)

Du kannst die Breite für die Programme im Setup einstellen.

Grüße

kamel5

Neue Version 1.1.17 im git:

- Fixed missing progress bar for DVD replay

- Some optimization

- Added support for recording image to replay progress bar

- Display recording image even if no scraper poster is available

- Update Makefile

- Add various icons

- Add parental rating to the text window

- Add parental rating to the detail view

- Display duration also in hours

- Display scroll bar also if content is not scrollable

- Correct a font size in the detailview

- Swap time/date and shorttext in the display replay

- Correct progressbar in the cNopacityScheduleMenuItem

- Make the duration of a recording configurable

- Display free disk space in the main menu in hours

- Update file de_DE.po

- Display event duration/seen/remaining time in the display channel also in hours

- Delete logoWidth and logoHeight in config.c as the are like logoWidthOriginal and logoHeightOriginal

- Add frame parameters (VDR >= 2.6.5) to menudetailview

- Also support of channel logos with "~" in the name

- Optimize progress bar in display channel

- Fix menu item cannot be edited when animation is active

- Fix menu item editable width

- Better shortening of "Title" and "Subtitle" in the detail view

- Rework setup.c

- Added setup option for detail view to show title and subtitle truncated or line-wrapped

Vielen Dank an shofmann für die Verbesserungsvorschläge, Bug-Berichte und das Testen.

Grüße

kamel5

Ich habe das mal mit einem ungepatchten VDR und dem frisch geclonten Plugin probiert.

Bei mir kompiliert das dann ohne Problem mit VDR-2.6.4:

Compiling with GraphicsMagick++
CC config.o
g++ -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -O0 -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE  -I/home/DVB/Test1/vdr/include -c -DPLUGIN_NAME_I18N='"skinsimple"'  -I/usr/include/GraphicsMagick -o config.o config.c
CC displaychannel.o
g++ -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -O0 -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE  -I/home/DVB/Test1/vdr/include -c -DPLUGIN_NAME_I18N='"skinsimple"'  -I/usr/include/GraphicsMagick -o displaychannel.o displaychannel.c
CC displaymenu.o
g++ -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -O0 -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE  -I/home/DVB/Test1/vdr/include -c -DPLUGIN_NAME_I18N='"skinsimple"'  -I/usr/include/GraphicsMagick -o displaymenu.o displaymenu.c
CC displaymessage.o
.
.
.
g++ -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -O0 -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE  -I/home/DVB/Test1/vdr/include -c -DPLUGIN_NAME_I18N='"skinsimple"'  -I/usr/include/GraphicsMagick -o status.o status.c
CC volumebox.o
g++ -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -O0 -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE  -I/home/DVB/Test1/vdr/include -c -DPLUGIN_NAME_I18N='"skinsimple"'  -I/usr/include/GraphicsMagick -o volumebox.o volumebox.c
CC skinsimple.o
g++ -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -O0 -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE  -I/home/DVB/Test1/vdr/include -c -DPLUGIN_NAME_I18N='"skinsimple"'  -I/usr/include/GraphicsMagick -o skinsimple.o skinsimple.c
LD libvdr-skinsimple.so
g++ -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -O0 -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE  -I/home/DVB/Test1/vdr/include  -shared config.o displaychannel.o displaymenu.o displaymessage.o displayreplay.o displaytracks.o displayvolume.o imagemagickwrapper.o imagescaler.o imageloader.o messagebox.o tools.o simple.o setup.o status.o volumebox.o skinsimple.o -lGraphicsMagick++ -lGraphicsMagick -o libvdr-skinsimple.so
IN install-lib
install -D libvdr-skinsimple.so /home/DVB/Test1/vdr/PLUGINS/lib/libvdr-skinsimple.so.2.6.3

Er macht dann allerdings eine "libvdr-skinsimple.so.2.6.3" daraus, weil die API-Version nicht erhöht wurde.

Du müsstest also nochmal schauen, was da bei Dir schief läuft. Vorher vielleicht überall mal ein "make clean" machen, vor dem Bauen...

Grüße

kamel5

Bei VDR <= 2.6.4 sollte das eigentlich durch die vorherige if-Abfrage (#if (APIVERSNUM >= 20605) nicht mit übersetzt werden.

Wenn das nicht klappt, müste ich da nochmal schauen.

Grüße

kamel5

Welche VDR-Version nutzt Du? Hast Du auch die richtigen VDR-Header Files beim Übersetzen?

Diese Funktion gibt es ja erst seit VDR 2.6.5.

Grü0e

kamel5

Zitat von Paulaner

Damit bin ich noch nie so richtig glücklich geworden, weil ich dann oftmals zu weit springe.

Das ging mir am Anfang auch so. Ich habe dann die Sprungweite für Wiederholung etwas niedriger eingestellt. Damit hat man dann etwas mehr Kontrolle.

Grüße

kamel5

Zitat von Paulaner

Das Verschieben der Sprungmarken ist doch glaub ich nur wirksam, wenn man die Wiedergabe pausiert?

Ja, aber 7 und 9 ist auch schon belegt, springt an den Anfang oder das Ende einer Aufnahme ohne Sprungmarken.

Was Du aber machen kannst: im Hauptmenü->Einstellungen->Wiedergabe: die Sprungweite für Grün/Gelb nach Deinen Wünschen für mit und Ohne Wiederholung einzustellen (ist auch schon so vorkonfiguriert). Dann kannst Du durch Festhalten der Taste eine größere Sprungweite erzielen.

Grüße

kamel5

Danke für die Unterstützung bei der Lösung dieses Problems.

Der entsprechende commit ist jetzt im git.

Grüße

kamel5