VDR Portal

Hi,

nutzt jemand schon den vdr 1.7.12 mit der eHD [incl. der aktuellen Plugins aus dem SVN Reel]?
http://www.vdrportal.de/board/thread.php…htuser=0&page=1

und OSD in 720x576 Patch
http://www.vdrportal.de/board/thread.php?threadid=93068

Ich muß leider wegend ´dem NetCeiver den VDR 1.7.0 verlassen und
auf eine andere Version wechseln nur auf welchen Version?

Ich denke das TS Problem /Schnittmarkenproblem gibt es noch immer beim vdr 1.7.12?

Welche Patches werden für dien vdr 1.7.12 benötigt damit die reel Plugins und der reelskin3 laufen?

Ja da kommen Fragen über Fragen auf bei diesem Thema.

Wo finde ich den Link für die Basis Patches "vdr179-rmm_svn13781-patch.diff" für den VDR?
gefunden unter:
http://www.vdrportal.de/board/thread.php?threadid=90975

Grüße
cinfo

Ich habe an Copperhead einen Patch für seinen Extensions Patch für VDR 1.7.12 geschickt. Den wird er wohl demnächst einbauen.
Der implementiert aber ausschließlich die Funktionalität für das Reelbox-Plugin. Skinreel geht damit nicht.
Außerdem habe ich ihm auch einen Patch für das Reelbox-Plugin geschickt. Weil die Option im Ext.Patch und der Patch für das Reelbox-Plugin nur zusammen funktionieren.

Skinreel halte ich persönlich für nicht so wichtig. Inzwischen gibts doch auch ganz schöne Skins für den VDR direkt, die ohne Patchereien laufen.
Außerdem sind die Eingriffe in den VDR für das Skinreel recht kräftig. Da gab es ja auch Wechselwirkungen mit anderne Patches usw.

Quoted

Original von HTPC-Schrauber
Ich habe an Copperhead einen Patch für seinen Extensions Patch für VDR 1.7.12 geschickt. Den wird er wohl demnächst einbauen.
Der implementiert aber ausschließlich die Funktionalität für das Reelbox-Plugin. Skinreel geht damit nicht.
Außerdem habe ich ihm auch einen Patch für das Reelbox-Plugin geschickt. Weil die Option im Ext.Patch und der Patch für das Reelbox-Plugin nur zusammen funktionieren.

Skinreel halte ich persönlich für nicht so wichtig. Inzwischen gibts doch auch ganz schöne Skins für den VDR direkt, die ohne Patchereien laufen.
Außerdem sind die Eingriffe in den VDR für das Skinreel recht kräftig. Da gab es ja auch Wechselwirkungen mit anderne Patches usw.

Sind die Patche auch mit aktuellen Plugin-Versionen zu gebrauchen? Ich habe in der Vergangenheit immer ziemliche Probleme gehabt, alles halbwegs passend zusammen zu bekommen, weil die Patches nur mit teilweise monatealten Ständen funktionierten. Ein Hinweis irgendwo im Patch, welche Pluigin - Version benötigt wird wäre hilfreich.

Falk

Der Patch geht gegen das jetzt aktuelle SVN.
Du hast Recht. Ich sollte die SVN-Version noch in den Patchnamen integrieren.

Wobei inzwischen auch nicht mehr so viel Bewegung im Reelbox-Plugin ist wie früher. D.h. der Patch sollte länger funktionieren.

Es gibt leider keine richtige Versionierung bei Reel. Daher kann man das Problem kaum umgehen.
Und im Original-VDR so lange rumzupatchen, bis das Plugin ohne Änderungen kompiliert, das halte ich für keine gute Lösung.
Ich habe sogar andersherum versucht so wenig wie möglich Änderungen am VDR zu machen. Dafür ist etwas mehr am Plugin nötig.

Leider musste ich auch feststellen, das meine C++-Kenntnisse noch nicht ausreichend sind, um das Reelbox-Plugin fehlerfrei lauffähig zu bekommen ganz ohne Änderungen am VDR.
Ich hatte das zwar geschafft, das es mit einem Vanilla-VDR lief. Dann funktionierte aber das Bildeinstellungs-Menü nicht mehr. Da kam nur noch ein leeres Fenster. Und ich hab es nicht hinbekommen, das es geht. Deswegen musste ich dafür noch Änderungen im VDR vornehmen.
Verstehen tu ich das Problem (noch) nicht. Ich bin zwar beruflich Programmierer. Aber mit C++ bin ich neu.

Quoted

Ich bin zwar beruflich Programmierer. Aber mit C++ bin ich neu.

Genau das ist auch mein Problem

Wenn Copperhead den Patch fertig hat, werden ich mal testen. Danke schon mal für deine Mühe.


Falk

hi,

ich weis nicht ob ihr die vdr ml verfolgt aber ich habe erstmal "nur" die 1.7.10 in betrieb bis die sache mit der PCR pid geklärt ist

@spitzb
ich kann gern nochmal ein diff mit vdr 1.7.10 gegen den aktuellen rmm svn machen und hier reinstellen


@HTPC-Schrauber

> Es gibt leider keine richtige Versionierung bei Reel. Daher kann man das
> Problem kaum umgehen

man kann beim svn checkout die version nehmen die im patch steht oder man kann im svn schauen wann die letzten änderungen am entsprechenden plugin im svn waren und davor auschecken

die "richtige Versionierung" wäre imho die svn nummer die in den stable zweig übernommen wird

Quoted

ich kann gern nochmal ein diff mit vdr 1.7.10 gegen den aktuellen rmm svn machen und hier reinstellen

Danke für das Angebot, IG88. Ich habe aber im Moment schon 1.7.11 erfolgreich in Betrieb.
Aber vielleicht hat jemand anderes Interesse daran.

Falk

Hi,

Quoted

ich kann gern nochmal ein diff mit vdr 1.7.10 gegen den aktuellen rmm svn machen und hier reinstellen

mich würde die fes Interesssieren für die Version 1.7.12.
Aber sollten die Patches von 1.7.10 nicht auch passen.
Wenn nicht mache ich gerne die Anpassungen hierzu.

Wäre auch Skinreel möglich?
Der alte "vdr-1.7.y-skinreel3-vdr-osd_v2.diff" Patch lässt sich schon einmal ohne Fehler installieren.

Grüße
cinfo

Du koenntest es mal damit testen:
Plugin BigPack fuer VDR 1.7.12

Hi,

bin ich schon dabei. Den Patch für den reelskin3 konnte ich auch noch zusätzlich installieren.

Welche Patches hattest Du für die Reel Plugins benutzt?

Es ist auch schön das sie Sachen vom NetCeiver "mcli" Plugin mit an Board sind.

Leider gehen eine menge Plugins z.B. "burn" nicht durch.
Vielleicht gibt es ja in Deinem Fred auch noch Unterstützung dazu.
http://www.vdrportal.de/board/thread.php…htuser=0&page=3


Grüße
cinfo

Quoted

Original von cinfo
Leider gehen eine menge Plugins z.B. "burn" nicht durch.
Vielleicht gibt es ja in Deinem Fred auch noch Unterstützung dazu.

Das liegt dann aber an der Entwicklungsumgebung. Unter Gen2VDR V3 haben alle durchkompiliert. Poste Deine Fehlermeldungen dort, und danke fuer den mcli Hinweis !

hi,

irgendwie habe ich das gefühl es läuft in die falsche richtung
erst sollte man den patch für den vanilla vdr anpassen und evtl. parallel für den extension patch wobei das auch auseinander läuft den da gibt es mitlerweile auch mehrere versionen von verschiedenen leuten (eigentlich von zulu)

@spitzb
das eine änderung am recordingformat in der 1.7.11/12 drin ist hast du gesehen?
ich bin da eher vorsichtig wenn am recordingformat geändert wird
es gab da ein paar diskussionen auf der ml um die abspielbarkeit mit anderen playern und solange das noch offen ist stelle ich das an meinem produktiv laufenden vdr nicht um

1.7.11
- The PCR pid in generated PMTs is now set to 0x1FFF ("no PCR pid") in
cPatPmtGenerator::GeneratePmt(), because VDR doesn't record the PCR pid.

1.7.12
- The PCR pid in generated PMTs is now set to the channel's PCR pid again.
- The PCR pid is now recorded for channels where this is different from the video
PID. To facilitate this, the interfaces of cTransfer, cTransferControl, cRecorder
and cReceiver have been modified, so that the PIDs are no longer given in separate
parameters, but rather the whole channel is handed down for processing. The old
constructor of cReceiver is still available, but it is recommended to plugin authors
that they switch to the new interface as soon as possible.
When replaying such a recording, the PCR packets are sent to PlayTsVideo()



generell ist es so das je weiter sich der original vdr im bereich ts und osd eintwicklet desto größer werden die probleme mit dem existierenden patch, der ist eigentlich nur für pes gemacht und auch die ts daten werden im moment (>vdr 1.7.3) imho über die pes-funktionen abgespielt was so leidlich funktioniert aber z.b. schon folgen beim schneiden und den sprungmarken zeigt
solange nicht jemand den patch für das reelbox plugin umkrempelt wird das imho nix, ähnliches gilt auch für das osd da kls den bereich ja auch grade in richtung mehr auflösung und mehr farben weiter entwickelt - rmm hat halt in genau diesen bereichen ihren von vdr 1.4 abgeleiteten vdr schon vor längerer zeit erweitert und weiter entwickelt und das reelbox plugin ist halt auf diese rmm-vdr erweiterungen hin programmiert

Ja, ich habe die Änderungen mitverfolgt, für mich aber keine Auswirkungen gesehen. Aktuell läuft bei mir 1.7.11 und das zu meiner Zufriedenheit. Auf die Schnittfunktion kann ich im Moment verzichten, wenn's auch etwas schmerzt. Aber da gibt es nicht nur in Verbindung mit dem rmm-Plugin Probleme. Ich habe auf einem Testrechner noch eine xine-Lösung laufen, bei der das Schneiden zwar klappt, aber zumindest bei HD - Aufzeichnungen gibt es Probleme, wenn man beim Abspielen über die Schnittstelle kommt. Die eHD brauch einen Vorwärtssprung um neu zu synchronisieren, Xine hängt sich gerne auf (

Es wird ja immer noch ein Freiwilliger gesucht, der das Reelbox - Plugin so umbaut, dass es möglichst ohne Patcherei mit einem aktuellen VDR zusammenspielt. Ich würd's ja tun, habe aber leider nicht die nötige Kenne. Irgendwer wollte mal PlayTS() einbauen, davon habe ich aber auch nichts mehr gehört.

Es ist ein wenig Schade, dass sich niemand findet, der das mal in die Hand nimmt. Die eHD - Lösung ist meiner Ansicht nach nicht die Schlechteste. Auch Reel sollte sich da angesprochen fühlen. Immerhin haben sie bestimmt eine ganz hübsche Anzahl von eHD's verkauft. Für Reel wäre es mit Sicherheit ein Leichtes, das Plugin so zu überarbeiten, dass es sauber mit neueren VDR's läuft.

Falk

Ich stelle heute abend mal meinen Patch für den Vanilla-VDR rein incl. zugehörigem Patch für das aktuelle Reelbox-Plugin hier rein. Das ist auch das, was Copperhead in den Ext.Patch aufnimmt.

Ich habe den Patch für den VDR auf Basis des alten Patches neu aufgebaut und nur das Nötigste rein genommen. Daher sind die Änderungen am VDR recht gering.
Ein Skinreel läuft damit nicht. Das war aber auch gar nicht mein Ziel. Es gibt auch hübsche Skins direkt für den VDR.

Eigentlich wäre es aus meiner Sicht sinnvoll, wenn man einen Ableger vom Reelbox-Plugin baut und diesen unabhängig vom Originalen Reelbox-Plugin weiter entwickelt. Ich weiß das solche Ableger oft nicht so gerne gesehen sind. Auf Dauer halte ich es aber für die einzig gangbare Lösung, da sich der ReelVDR und der Vanilla-VDR eher immer noch weiter auseinander entwickeln werden. Und die Probleme damit immer größer werden.

Ich hatte schon daran überlegt das anzufangen. Zumindest mal so, das man möglichst viele Reel-spezifische Sachen aus dem Reelbox-Plugin heraus nimmt. So das man am Ende schauen kann was noch übrig bleibt und sozusagen ein ExtensionHD-Plugin heraus bekommt.
Leider musste ich aber feststellen das meine Kenntnisse in C++ und vor allem auch mein Verständniss der VDR und eHD Internas nicht ausreichen, um die Entwicklung entsprechend voran zu treiben.
Einige Sachen kann ich machen. Aber das sind eher einfachere Dinge. Wenns tiefer rein geht reicht es einfach (noch) nicht.

Insgesamt bin ich aber der Meinung, das man auf die Tour durchaus zu einem besseren Plugin für die eHD kommen kann. Und vor allem auch einem das auch ganz ohne Patchereien am VDR auskommt.


EDIT: OK, nach dem letzten Beitrag von spitzb werd ich mal die Fleißarbeit anfangen und den Reelbox und Reelskin Kram aus dem Reelbox-Plugin heraus reißen. Mal sehen wieviel übrig bleibt. Für den VDR brauch ich aber auch jetzt schon nur noch 2 neue Methoden, damit es läuft. Ich hab schon rumgebastelt, aber die krieg ich leider noch nicht weg, weil dann immer das Bildeinstellungs-Menü nicht mehr funktioniert.
Aber mal sehen. Vielleicht kann uns nach einem gemachten Anfang auch hier und da mal ein "Wissender" unter die Arme greifen.

@HTPC-Schrauber

ich habe da zweifel ob es wirklich machbar/sinnvoll ist ein eigenes plugin zu bauen
das plugin hängt ja auch vom kerneltreiber und linux.bin/hdplayer ab
außerdem ist da noch das xnemediaplayer plugin und die darum gelagerten plugins für die medienwiedergabe (die über xinemediaplayer abspielen), da werden die meisten nicht drauf verzichten wollen und wenn man das alles einigermaßen mit bei der stange halten will ...?

ein "natives" vdr 1.7 plugin klingt nicht schlecht aber wie werden dann z.b mkv's oder avi's abgespielt? wer zerlegt die datenströme und wie kommen die dann in die karte zurück? im moment macht das das xinemediaplayer plugin mit dem xine-ehd plugin

vieleicht ist ja der blick auf das output plugin der tt 6400 hd ff-karte eine hilfe?
http://powarman.dyndns.org/hgwebdir.cgi/dvbhddevice/

So, hier nun erstmal die beiden Patches.
Wie gesagt geht der VDR-Patch gegen den Vanilla-VDR.

Quoted

Original von IG88
@HTPC-Schrauber

ich habe da zweifel ob es wirklich machbar/sinnvoll ist ein eigenes plugin zu bauen
das plugin hängt ja auch vom kerneltreiber und linux.bin/hdplayer ab
außerdem ist da noch das xnemediaplayer plugin und die darum gelagerten plugins für die medienwiedergabe (die über xinemediaplayer abspielen), da werden die meisten nicht drauf verzichten wollen und wenn man das alles einigermaßen mit bei der stange halten will ...?

ein "natives" vdr 1.7 plugin klingt nicht schlecht aber wie werden dann z.b mkv's oder avi's abgespielt? wer zerlegt die datenströme und wie kommen die dann in die karte zurück? im moment macht das das xinemediaplayer plugin mit dem xine-ehd plugin

vieleicht ist ja der blick auf das output plugin der tt 6400 hd ff-karte eine hilfe?
http://powarman.dyndns.org/hgwebdir.cgi/dvbhddevice/

Also mich interessiert das ganze Drumherum nicht so wirklich. Nach meinem Empfinden sollte ein eHD - Plugin wirklich nur ein HD-Output-Device implementieren.

Die erweiterte Medienwiedergabe gehört in ein anderes Plugin, das ev. auf dem eHD - Plugin aufbaut.

Falk

Sehe ich auch so.
Abgesehen davon geht xinemediaplayer meines Wissens am Reelbox-Plugin vorbei. Daher sollte das dann trotzdem noch laufen.

Abgesehen davon hab ich ja nicht gesagt, das man ein völlig neues Plugin scheiben sollte. Das wäre wohl aussichtslos.

Ich hab mal alles REELVDR, RBLITE und SKINREEL raus geworfen. Das Ding läuft natürlich immer noch. Ein paar Sachen sind weg gefallen. Insgesamt ist es aber noch immer ein fetter Klotz.

Nun müsste eigentlich nur noch das TrueColor-Osd Zeug raus. Das wird im Reelbox-Plugin an sich nur an einer einzigen Stelle benutzt. Nämlich in dem Bildeinstellungs-Menü. Ich verstehe dummerweise noch nicht wie das funktioniert. Wenn ich von der Methode NewTrueColorOsd auf NewOsd umstellen, was das normale wäre, dann kommt der Hintergrund von den Bildeinstellungen aber keine Einstellbalken mehr. Und ich hab noch nicht begriffen, wie ich das hin bekomme.

Das aber auch meinen mangelhaften Kenntnissen in C++ und OO geschuldet. Ich bin normal Entwickler am Großrechner und ausschließlich strukturiert. Entwickeln unter Linux ist Neuland. Und OO auch. C++ ist nur rudimentär vorhanden.
Blöderweise schaff ich es noch nicht mal die Stelle mit GDB zu debuggen. Da ist unser Debugger am Großrechner komfortabler

Sollte sich jemand berufen fühlen mir eine kurze Einweisung in GDB zu geben oder sonstige Hilfestellung, dann nehm ich die gerne entgegen.

Die TrueColorOsd-Geschichte hab ich noch nicht geändert, weil noch immer nicht richtig verstanden.

Allerdings ist mir noch das Ganze BSP-15 Gedöns für die ReelBox-Lite aufgefallen. Das ist ja für uns auch irrelevant, weil wir keinen BSP-15 haben sondern den DeCypher. Ich habe das jetzt alles ausgebaut. Damit wird das Ganze nochmal deutlich kleiner.

Freilich hat mich das bisher noch nicht weiter gebracht in Bezug auf Plugin für Vanilla-VDR. Ich wollte erstmal etwas Komplexität raus nehmen. Vor allem war das Plugin ja so aufgebaut, das es sowohl den DeCypher als auch BSP-15 bedienen kann. Und das war einiges an Aufwand.
Mal sehen wie ich nun weiter mache.

Im Übrigen, ohne es probiert zu haben, sollten zum jetzigen Zeitpunkt xinemediaplayer und so auch immer noch laufen.

Wenn du schon größere Änderungen machst, kannst du auch gleich das fest verdrahtete /dev/fb0 in ein /dev/fbehd ändern?

Ich habe das selbst so gemacht. Dann setzt man einfach einen symbolischen link vom tatsächlichen fb - device aus /dev/fbehd.

Falk