Moin!
Zum Teil bin ich da schon bei. Mit dynamite ist es z.B. möglich, bestimmten Karten feste "vdr-Nummern" zuzuordnen.
Mit "das Übel bei der Wurzel packen" meinte ich natürlich, es im Treiber zu lösen, nicht in den Applikationen rumzufrickeln 
Klaus
// Flamewar on
Das stimmt so nicht, die schliessende geschweifte Klammer gehoert nicht eingerueckt
// Flamewar off
Der war gut!
Klaus
Das ist eins der Probleme: udev benennt nur die Devices um, ändert aber nicht die eigentliche Device-Nummer. Da VDR aber über die Device-Nummer unter /sys nachschlägt, geht das dann schief, wenn /dev/dvb/adapterX nicht mehr zu /sys/class/dvb/dvbX passt. Udev-Regeln funktionieren daher nicht.
Alternativ könnte man entweder VDR beibringen, symlinks zu interpretieren, z.b. /dev/dvb/primary -> /dev/dvb/adapter2 zu verfolgen, oder die Device-Nummer aus der device node Nummer zu interpretieren, was aber auch gewagt ist.
Wieso packt eigentlich nicht mal jemand dieses Übel bei der Wurzel?
Es müsste doch wohl auch möglich sein, das alles von vorneherein richtig zu benennen, so daß es auch vernünftig zusammenpasst, oder?
Klaus
Utf8ToArray muss ja eh irgendwann wegfallen, auf nen Unicode System besteht ja eigentlich gar kein Grund mehr irgendwas umzumappen
Also meine Systeme laufen alle mit ISO-8859-1, und das bleibt auch so!
Jegliche Änderung an VDR, die das verhindern würde, hat schon mal überhaupt keine Chance, übernommen zu werden
Zitat
Dabei fällt mir ein das ich schon immer mal wissen wollte was für einen Code Beautifier du nutzt? Uncrustify mit klaus.cfg schient es nicht ganz zu sein.
Ich verwende gar keinen "Code Beautifier". Ich schreibe den Code von Hand, so wie er gehört
Klaus
Alles anzeigenIch hab grad mal nachgeschaut, der Aufwand für ne Konfiguration frontend + adapter versus delivery system wäre nicht sehr hoch.
a) eine extra Konfigurationsdatei, z.B. sowas wie eine 'dvbdevice.conf'
<adapter>:<frontend>:<delsys0>,..,<delsysN>
b) ein Eingriff in cDvbDevice :: ProvidesDeliverySystem
(Kombi adapter/frontend in .conf nicht vorhanden = Verhalten wie bisher)
Mal sehn, ob sich sowas umsetzen lässt.
Das wird dann aber wohl ein "ewiger Patch" bleiben, denn mir gefällt das überhaupt nicht!
Wenn ein Device grundsätzlich DVB-T und DVB-C kann, wegen fehlendem Antennenanschluß aber definitiv nur eines davon möglich ist, dann sollte es bitteschön auch nur dieses an VDR melden!
Wobei mir gerade einfällt: wozu haben wir denn eigentlich die cDeviceHook?
Wenn du unbedingt sowas einbauen willst, dann müsste das doch da drüber gehen, oder?
Zumindest bleibt der Core-VDR dann verschont von einer weiteren Datei, in der Devices über Nummern konfiguriert werden müssen, und der Plugin-Autor kann das gestalten, wie er will.
Klaus
Alles anzeigen
Dieser Argumentation kann ich nicht so ganz folgen:
Wieso sollte sich der Treiber dafür interessieren, was wo angeschlossen ist?
Die Zuordnung "Signal -> Karte" ist Sache der Anwendung.
Bei SAT kann man ja bereits verschiedene DiSEqC- /SCR-Einstellungen den Karten zuordnen.
Genauso sollte es möglich sein, ein bestimmtes DVB-T bzw. DVB-C Signal einer Karte zuzuordnen.
Eine Treiberoption für DVB-T-only oder DVB-C-only ist eine Krücke. So, als wollte man per Treiberparameter SAT-Positionen festlegen.
Da kann ich nun wieder nicht so ganz folgen
Der Treiber sagt der Applikation, welche Systeme die Karte kann, also ob DVB-S, -C oder -T.
Natürlich sagt er bei DVB-S nichts darüber aus, welche Satelliten damit empfangbar sind. Das hängt ja von diversen Parametern ab wie geographische Lage und Antennenausrichtung.
Genausowenig sagt er bei DVB-C oder -T etwas darüber aus, welche Kanäle man empfangen kann. Das hängt ja auch wieder vom Ort des Geschehens ab.
Aber daß man bei einer Karte, von der der Treiber behauptet, sie könne DVB-T, auch tatsächlich DVB-T empfangen kann, wenn man das Frontend entsprechend konfiguriert, darauf sollte sich eine Applikation doch wohl verlassen können. Ansonsten macht es doch keinen Sinn, daß der Treiber auf Nachfrage sagt, die Karte kann DVB-T - und wenn's dann drauf ankommt, dann geht's doch nicht.
Zitat
Ähnlich wie bei SAT kann man theoretisch z.B. auch 2 verschiedene DVB-T Signale haben, die an eigene Frontends angeschlossen sind. Spätestens dies ist nicht mehr per Treiberoption zu machen.
Das dürfte ja wohl ein höchst theoretischer Fall sein, denn normalerweise liegen die DVB-T-Frequenzen ja wohl so, daß man sie alle in ein Kabel zusammenmischen kann.
Klaus
Alles anzeigenDu kannst hier nur Zeichen von 0x01 bis 0xFF zurückgeben, die dann als echte Zeichen interpretiert werden. Multi-Byte-Sequenzen werden als Funktionstasten etc. interpretiert (siehe KbdMap[]).
Du solltest also innerhalb von cKbdRemote::ReadKeySequence() ermitteln, ob es sich um ein UTF-8-Zeichen handelt und dieses dann mit Utf8ToArray() in ein 1-Byte Zeichen umwandeln. Sollte der resultierende Wert größer als 0xFF sein, ist das Zeichen nicht verwertbar.
[quote]
Und dahinter kommen dann nocht Dinge wie z.B in menuitems.c die höhere Unicodezeichen eh zerstören.
--
if (c <= 0xFF) { // FIXME what about other UTF-8 characters?
--
das muss man dann wohl mal Schrittweise angehen.
Wie gesagt, soweit ich das sehe muß sich das alles innerhalb von ReadKeySequence() abspielen.
Vielleicht geht es ja so:
if (key1 == 0x1B) {
// Start of escape sequence
...
}
else if (key1 == 0xC3) {
// Start of UTF-8 sequence
... hier deinen neuen Code einbauen
}
Dabei fällt mir auf, daß diese ganze Sequenz falsch eingerückt ist...
Klaus
Mit UTF-8 stehe ich persönlich auf Kriegsfuß und benutze es nicht. Wie man sieht, macht es immer wieder Probleme
Ich vermute mal, daß irgendwo ein Aufruf an Utf8ToArray() helfen könnte.
Aber wo und wie genau müsste wohl jemand probieren, der UTF-8 benutzt.
Klaus
@Klaus: Magst du hier mal reinschauen? Tastatur im VDR ist deutsch erzeugt aber keine Umlaute
Soweit ich das jetzt sehe ist da ganz einfach nen Bug im VDR, auf nem utf-8 System gehen bei der Tastatureingabe keine Umlaute mehr.
Im letzten Posting dieses Threads heißt es
Zitat von Keine_Ahnung
Edit: Jup, auf de_DE@euro gehts.
Bedeutet das, daß damit der Fehler nicht mehr auftritt?
Klaus
Ich habe diese Änderung rückgängig gemacht.
Ja, damit sieht es wieder so aus wie bisher.
OK. Ich habe die Änderung für die 1.7.24 wieder rückgängig gemacht.
Der Patch stammte von sundararaj.reel@googlemail.com und hat auf mich eigentlich plausibel gewirkt:
Zitat von sundararaj.reelAlles anzeigen
In recording.c:1108, stat() is used to get the file status. But a
couple of lines later, S_ISLNK() is used to check if the file is a
symbolic link which is always false.
Shouldn't lstat() be used in line 1108 instead of stat() when testing for links?
From http://linux.die.net/man/2/stat
stat() stats the file pointed to by path and fills in buf.
lstat() is identical to stat(), except that if path is a symbolic
link, then the link itself is stat-ed, not the file that it refers to.
To reproduce the error: make paths in recordings directory with 6 or
more links in it. Vdr traverses this path even when MAX_LINK_LEVEL
should forbid it.
Klaus
Moin!
Das hilft nicht, wenn man eine DVB-C- und eine DVB-T-Karte hat und die DVB-C-Karte ein Hybridmodell ist.
Die Treiber haben so eine Option leider auch meistens nicht (hätte ich mir schon vor der API-Änderung gewünscht).
Genau da gehört diese Einstellung aber, finde ich, hin.
Wenn die Karte der Applikation meldet, daß sie DVB-C oder DVB-T kann, dann muß sie dieses "Versprechen" auch halten.
Wenn es von der Hardware her nicht möglich ist, beide Antennenkabel gleichzeitig anzuschließen (man also sowieso nur *eine* der beiden Varianten nutzen kann), dann macht es wenig Sinn, wenn der Applikation gesagt wird, daß beide Systeme empfangen werden können.
Ich schlage also vor, in den jeweiligen Treiber eine entsprechende Option einzubauen.
Zitat
So langsam wird die Device-Verwaltung im vdr sehr anspruchsvoll... Ich würde mir eine Konfiguration über udev wünschen, aber ich weiß nicht, was du von einer Abhängigkeit von libudev hälst.
Wenig - um nicht zu sagen *gar nichts*
Zitat
Das hätte dann aber auch den Vorteil, dass eine Änderung der Reihenfolge der Karteninitialisierung nicht gleich den ganzen vdr aus der Bahn wirft.
Wieso müsste hierfür denn VDR von libudev "abhängig" sein?
Ich dachte, mit UDEV-Regeln wird bestimmt, in welcher Reihenfolge die Devices erzeugt werden. VDR benutzt sie halt dann in der vorgefundenen Reihenfolge (ohne irgend etwas von "UDEV" zu wissen).
Klaus
Hat das irgendwelche Vorteile?
Da ist z.B. der Treiber für die TT-S2 6400 mit drin
Zitat
Was spricht denn dagegen den Patch von Urig mit in den VDR zu übernehmen?
Ich möchte halt nicht ewig alle möglichen alten Treiberversionen unterstützen müssen.
Klaus
Das fiel mir nachts auch ein, dass ich nachsehen wollte, ob das berücksichtigt wurde.
Als Vorschlag: eine "Device-Nr."-Zeile in der source.conf?
Halte ich für keine gute Idee.
Das sind aber auch "dämliche" Devices
Hat denn vielleicht der Treiber eine Option, um das jeweils nicht verwendete System zu deaktivieren?
Oder einfach in der channels.conf keine Einträge für das nicht verwendete System machen. Dann
kommt VDR auch nicht auf die Idee, es zu benutzen.
Klaus
Alles anzeigenSymbolische Links werden bei mir jetzt gar nicht mehr angezeigt.
Meine Konfiguration sieht so aus, das ich im Aufnahmeverzeichnis mehrere Links auf Ordner, die sich über nfs auf einem NAS befinden, liegen habe.
Diese wurden bisher ohne Probleme bei aktivem NAS angezeigt, bei inaktivem NAS ignoriert.
Außerdem wird jetzt bei den Aufnahmen ein Ordner "video" angezeigt, der so eigentlich nicht vorhanden sein sollte.
Es gibt zwar einen symbolischen Link /video.ori-->/server/home/video, in dem die Ordner video0, video1, video2 liegen. Davon werden in der Aufnahmenliste unter video aber nur die Ordner video0 und video1 angezeigt.
Das Ganze ist ein wenig verwirrend. Das Aufnahmeverzeichnis liegt bei mir unter /home/video0, dieses wurde mit "-v /home/video0" dem VDR bekannt gegeben. In diesem Ordner liegen die oben genannten Links. Der VDR sollte also die Orner /video oder /video.ori normalerweise nicht kennen.
Soweit ich das jetzt probieren konnte, tritt das Problem mit der alten recording.c aus 1.7.22 nicht auf.
Kannst du testweise bitte mal diese Änderung rückgängig machen?
--- recording.c 2011/12/04 13:51:44 2.39
+++ recording.c 2011/12/10 14:12:55 2.40
@@ -1105,7 +1105,7 @@
if (strcmp(e->d_name, ".") && strcmp(e->d_name, "..")) {
char *buffer = strdup(AddDirectory(DirName, e->d_name));
struct stat st;
- if (stat(buffer, &st) == 0) {
+ if (lstat(buffer, &st) == 0) {
int Link = 0;
if (S_ISLNK(st.st_mode)) {
if (LinkLevel > MAX_LINK_LEVEL) {Klaus
Alles anzeigenHallo kls,
ist das so gewollt?
dvbdevice.c1133
Code#if DVB_API_VERSION > 5 || DVB_API_VERSION_MINOR >= 5
Wäre nicht das besser:
Code#if (DVB_API_VERSION << 8 | DVB_API_VERSION_MINOR) >= 0x0505
Im Prinzip hast du natürlich Recht, aber in dvbdevice.h wird ja bereits gefordert, daß DVB_API_VERSION mindestens 5 ist.
Deine Notation gefällt mir aber auch gut, werde sie wohl übernehmen.
Klaus
Ich hab den alten S2API-Wrapper aufgefrischt, damit er DVB API 5.3 emulieren kann, damit kann man wieder einen lauffähigen VDR übersetzen, ohne auf Linux-3.0 upgraden zu müssen.
Also ich verwende hier openSUSE 11.4 mit Kernel 2.6.37.6.
Man muß also nicht gleich kernelmäßig auf Linux-3.0 wechseln.
Den Treiber hole ich mir mit
hg clone http://linuxtv.org/hg/~endriss/media_build_experimental
cd media_build_experimental
make download
make untarKlaus
Ich bin dazu zu faul. Ich will ja nichts von der Mailingiste, sondern was bringen.
Da es ja niemanden zu intressieren scheint. Habe ich mal näher geguckt.
Ich lese zwar hier immer wieder mit, aber dieser Thread ist mir anscheinend echt durch die Lappen gegangen
Am sichersten ist es immer, mir sowas per Email zu schicken (muß nicht über die VDR-ML gehen).
Danke jedenfalls fürs "gucken".
ZitatAlles anzeigenDer Bug ist in VDR.
DiffAlles anzeigen--- remux.c.orig 2012-01-12 10:08:11.388006000 +0100 +++ remux.c 2012-01-12 10:11:14.245006788 +0100 @@ -700,8 +700,13 @@ if (offset) { uchar *p = data + offset - 6; if (p != data) { - p -= 3; - memmove(p, data, 4); + if (p - 3 < data) { + esyslog("ERROR: pointer before data offset=%d", offset); + } + else { + p -= 3; + memmove(p, data, 4); + } } int l = min(length - offset, MAXPESLENGTH); offset += l;
Dies fixt nur den Crash. Die Ursache, daß offset = 7 ist, muß nun wirklich jemand anderes suchen.
Edit: da war ein Fehler im diff.
Johns
Warum hier p < data wird ist schwer zu sagen, aber ich vermute mal, daß beim Umschalten ein paar kaputte TS-Pakete kommen.
Es macht also durchaus Sinn, an dieser Stelle p zu überprüfen. Zur Sicherheit würde ich dann sogar so weit gehen, einen Reset zu machen.
Kannst du bitte mal folgendes ausprobieren?
--- remux.c 2011/09/04 13:09:06 2.62
+++ remux.c 2012/01/12 12:07:58
@@ -701,6 +701,10 @@
uchar *p = data + offset - 6;
if (p != data) {
p -= 3;
+ if (p < data) {
+ Reset();
+ return NULL;
+ }
memmove(p, data, 4);
}
int l = min(length - offset, MAXPESLENGTH);Zum Testen kannst du vor dem Reset() ja noch eine Debug-Ausgabe reinmachen, um zu verifizieren, daß der Code auch wirklich mal durchlaufen wird.
Ich selber benutze eine FF-Karte für die Ausgabe, daher tritt der Fehler bei mir nicht auf und ich kann es auch selber schlecht testen.
Falls du in der HISTORY genannt werden möchtest, schick mir bitte eine Email mit deinem vollen Namen.
Klaus
Ich benutze folgende Adresse als Lesezeichen:
http://www.vdr-portal.de/index.php?form=Search&action=unread
Das geht schon ganz stark in die Richtung, die ich meinte.
Jetzt bräuchte ich nur noch eine "action" der Art "unread_since_last_visit" oder so.
Gibt es irgendwo eine Liste aller verfügbaren "actions"?
Kann man im Lesezeichen auch gleich mit angeben, daß man sich einloggen möchte?
Ich stelle mir das etwa so vor:
Klaus
Naja nicht ganz das was Du möchtest aber ich habe das Kennwort gespeichert und als Lesezeichen
http://www.vdr-portal.de/index.php?page=Portal
Das Lesezeichen verwende ich auch, aber mein Login muß ich trotzdem jedesmal eingeben. Das Einloggen stört mich auch gar nicht so sehr, es ist nur dieser Weiterleitungs-Link, dessen Sinn ich nicht verstehe, und daß ich explizit die Suche aufrufen muß. Das ist nämlich genau das, was ich jedesmal mache, wenn ich das Portal besuche, und das hätte ich halt gerne einfacher.
Klaus
Wenn ich mich beim VDR-Portal einlogge, dann kommt immer erst eine Seite mit einem Link, auf den ich klicken muß, damit ich weitergeleitet werde (ich könnte auch warten, bis das automatisch passiert, aber das dauert mir zu lange). Danach kann ich dann die Suchfunktion aufrufen, die mir alle Threads mit neuen Postings seit meinem letzten Besuch anzeigt.
Was ich gerne haben würde ist, daß ich nach dem Login sofort auf diese Seite komme. Ohne Klick auf den Weiterleitungs-Link (wozu braucht's den eigentlich?) und ohne extra diese Suchfunktion auszuwählen. Kann man das vielleicht irgendwo einstellen, daß das passiert?
Klaus
