Beiträge von horchi

Hi Monroe,

scheint am newplugin Skript zu liegen, das baut ein fehlerhaftes Makefile.
Im Makefile die Zeile:

APIVERSION = $(shell sed -ne '/define VDRVERSION/ { s/^.*"(.*)".*$$/\1/; p }' $(VDRDIR)/config.h)

sollte m.E. so aussehen:

APIVERSION = $(shell grep 'define APIVERSION ' $(VDRDIR)/config.h | awk '{ print $$3 }' | sed -e 's/"//g')

Grüße Horchi

Hi,

da Bedarf besteht habe ich das fertig für linvdr 0.7 übersetzte grep in der Version "(GNU grep) 2.5.1" (solange ich noch Platz habe) mal hier bereitgestellt.

http://www.jwendel.de/vdr/

Horchi

Hi,

nochmal zum Thema APIVERSION, bei mir ging's nach dem anpassen aller Plugin-Makefiles noch nicht. Ich hatte hartnäckig die Meldung:

...
...
Plugin weatherng:
ERROR: plugin weatherng doesn't honor APIVERSION - not compiled!
Plugin yaepg:
ERROR: plugin yaepg doesn't honor APIVERSION - not compiled!


*** plugins without APIVERSION: admin autotimeredit burn channelscan console control dvd extrecmenu femon graphtft image ipod mailbox mp3 nordlichtsepg osdteletext packets pin plain radio sc setup skincurses snapshot streamdev taste text2skin timeline tvonscreen undelete vcd vdrcd weatherng yaepg

Ursache, der im Makefile des VDR verwendete reguläre Ausdruck ist nicht mit der alten grep Version 2.4.2 der Debian 'oldstable' von linvdr kompatibel.

Abhilfe, entweder den regulären Ausdruck anpassen oder von gnu http://directory.fsf.org/grep.html die aktuelle grep Version (derzeit 2.5.1a) laden und übersetzen. Ich habe mich, um nicht bei jeder neuen VDR Version wieder ans Makefile zu müssen, für letzteres entschieden.

Vieleicht hilft es ja noch wem

Grüße Hochi

Hi TomG,

Zitat

Um festzustellen, ob es wirklich daran liegt (und nicht an Problemen mit anderen Patches), könntest du die Marken-Aktualisierung testweise abschalten: "Einstellungen - Wiedergabe - Intervall für Laden der Marken" auf 0 setzen.

Ich habe nun 'Sprung bei Schnittmarke' wieder aktiviert und dafür 'Intervall für Laden der Marken' auf 0 gesetzt. Ob es die Abstürze behebt kann ich noch nicht sagen, da diese ja sehr selten auftreten.

Ich habe mir nun nach deinem Hinweis zum 'laden der Marken' den Code nochmals angesehen und denke du liegst mit deiner Vermutung richtig.

Und ja, auch andere Patch oder Plugin Entwickler, welche das Verhalten des JumpPlay Patch nicht kennen und davon ausgehen, dass sich die Marken-Liste während der Wiedergabe nicht ändert können in diese Falle tappen.

Danke und Grüße
Horchi

gelöscht, sorry war doppelt geposted

Hi,

Ist das folgende Problem bekannt bzw. gibt es schon eine Lösung?

Ab und an stürzt der VDR beim wiedergeben der Aufnahmen ab, da diese recht selten passiert (ca. 1-2x/Woche) konnte ich es noch nicht mit und ohne BigPatch testen. Diesen Crash gibt es nun schon seit einigen Versionen, da es recht selten auftritt habe ich es bislang nicht weiter verfolgt und kann auch nicht sagen seit welcher Version es existiert.

Ich habe den Backtrace bereits in der ML gepostet und dort den Hinweis erhalten, dass es recht sicher nicht vom VDR sondern von einem der Patches kommt, da der plain VDR cMarks::Get() nicht aus cDvbPlayer::Action() aufruft.

Der Backtrace aus dem core:

> #0  Get__6cMarksi (this=0x8621f10, Position=8780) at recording.c:1429
> 1429          if (mi->position == Position)
> (gdb) bt
> #0  Get__6cMarksi (this=0x8621f10, Position=8780) at recording.c:1429
> #1  0x080a3546 in Action__10cDvbPlayer (this=0x87a77b8) at dvbplayer.c:692
> #2  0x080ff884 in StartThread__7cThreadP7cThread (Thread=0x87a77c4) at 
> thread.c:244
> #3  0xb7ee30ba in pthread_start_thread () from /lib/libpthread.so.0

in Zeile 1429 zeigt mi in den Wald => crash

Da fällt mir erst zunächst der Jump-Play Patch ein, der macht genau das:

+                       if (Setup.PlayJump && marks) {
+                          // check for end mark - jump to next start mark
+                          cMark *m = marks->Get(readIndex);
+                          if (m && (m->Index() & 0x01) != 0) {
+                             m = marks->Next(m);
+                             int Index;
+                             if (m)
+                                Index = m->position;
+                             else if (total == index->Last())

Da hier vorher 'Setup.PlayJump' abgefragt wird sollte das deaktivieren im Setup zum eingrenzen genügen. Ich schalte das nun einmal ab und berichte ob es dann auch auftritt. Kann aber etwas dauern, da ich ab Mi. im Urlaub bin
Vieleicht solllte ich noch erwähnen, dass es nicht an einer Marke crashed sondern mitten im Film!

Auch wenn durch den Get() Aufruf durch das JumpPlay Pacht ausgelöst wird, sollte der VDR in der for Schleife in Get() doch keinen ungültigen mi Pointer liefern, oder?

cMark *cMarks::Get(int Position)
{
  for (cMark *mi = First(); mi; mi = Next(mi)) {
      if (mi->position == Position)
         return mi;
      }
  return NULL;
}

- EDIT -
Nur so eine Idee, basteln hier möglicherweise zwei Threads gleichzeitig an marks, der eine löscht eine und der andere iteriert gerade in cMarks::Get() durch die Liste (oder so was ähnliches) !? Dann wüde Mutex helfen. (Sind aber ältere Aufnahmen, soll heißen noadd ist bei den Abstürzen nicht gleichzeitig daran am arbeiten)

Grüße Horchi

Hi carwasher,

absolut untestet, da ich hier keinen 1.3.36 verwende!

Hi viking,

schaue ich mir an, ich hoffe, dass ich noch vor meinem Oster-Urlaub dazu komme.

Hi carwasher,

wenn du das 'vdr-1.3.44-plain.diff' nimmst, gibt es nur 4 kleinere Rejects, die sollten einfach aufzulösen sein. Wenn nicht melde dich nochmal dann baue ich ein Patch.
Oder hat schon jemand eines?

Horchi

Hi,

das war's, läuft Prima :D!

Warum ist das auskommentiert? Soll so verhindert werden, dass man Remote das Device umschaltet, ich dachte dafür ist die Option 'Pausieren zulassen' gedacht?

Horchi

Hi schmirl,

Zitat

Original von schmirl
Hast Du im Source des streamdev-server Plugins die Kommentare beim Attach() und Detach() entfernt? Siehe [solve]Nach Update von Streamdev-server seltsames Verhalten

Nein habe ich nicht! Hört sich aber so an als wäre genau das mein Problem.
Ich kann leider erst heute Abend testen.

Danke für den Tip und Gruß
Horchi

Hallo,

nachdem ich nun viele Hinweisen aus dem Forum und Wiki durchgetestet habe schildere ich hier mal mein Problem.

Auf meinem WZ VDR (linvdr) Version 1.3.45, Kernel 2.6.16, Bigpatch und einigen Plugins läuft auch das stremdev-server Plugin. Das verbinden via HTTP und auch via steamdev-client ist enabled. Er steht auch auf immer pausieren.

Auf meinem Büro PC (SuSE 10.0) habe ich auch VDR 1.3.45 mit Bigpatch, dem Softdevice und dem Streamdev-client (+ div. weiteren Plugins) laufen. Das ansehen der Aufnahmen klappt ohne Probleme und das OSD ist auch da. Nur kann ich ausschließlich auf Kanäle des auf dem Server gewählten Transponders schalten, eben als würde dort eine Aufnahme laufen. Ist dieses Verhalten normal bzw. was mache ich hier falsch?

Mittels mplayer (HTTP Streaming) kann ich jedoch jeden Kanal wählen.

Die channels.conf clinet/server ist identisch.

Danke und Grüße
Horchi

Hallo Andreas,

Zitat

In der Beta2 habe ich diesbezüglich etwas geändert und um Feedback gebeten, das jedoch ausblieb (mit Ausnahme Dir).
Hast Du die Möglichkeit, die vorherige Beta zu testen?
Läuft es da besser?

Wenn die auch mit 1.3.45 (1.3.44) läuft ja, wo finde ich die Beta1?
Ich habe am Wochenende etwas aufgeräumt und alle älteren Versionen incl. der Quellen gelöscht.

Zitat

??? Wieso rufst Du den TV auf, wenn Du die Bilder nicht sehen willst ???
Oder meinst Du das Fehlverhalten, dass das Grabben läuft obwohl nichts angezeigt wird? Das sollte natürlich nicht sein.

Da habe ich mich etwas missverständlich ausgedrückt, ich meine warum wird öfter gergabt als die Anzeige aktualisiert wird bzw. werden soll?

Debuggen könne wir das gern, heute passt es aber nicht so gut.

Danke und Grüße
Horchi

Hi amair,

ich habe nun seit Samstag die aktuelle Beta am laufen. Funktioniert soweit gut. Nur das die Aktualisierung des TV Vorschau Bildes ruckelt und oft hängen bleibt. Im Log des VDR sehe ich trotzdem weiterhin zahlreiche grabs. Auch wenn ich die Aktualisierung auf 'aus' stelle wird leider auch weiter gegrabt.
Wenn die TV anzeige hängt muss ich nur kurz zurück auf einen anderen Menüpunkt (Zeitleiste, ..) dann läuft es meist wieder eine zeitlang. Bin ich der einzige mit diesem Verhalten?

Wozu dient das häufige aktualisieren des Bildes wenn es nicht verwendet wird?

Grüße Horchi

Hi,

Danke, läuft alles super

Horchi

Zitat

Original von modul77
Hallo,

kann ich das dann so machen, dass ich nur VDR 1.3.44 mit http://bigpatch.vdr-developer.…44-bigpatch-test2.tar.bz2 evtl. mit dem timercmd patch compiliere

Wie gesagt, den vdr-1.3.44-with-bigpatch-test2.diff vom PIN nicht vergessen

Zitat

Ich habe nämlich im XXV (aktuellste Version aus SVN-Repo) das Problem mit den doppelten und dreifachen Timern

Zu XXV kann ich sonst nichts sagen da ich davon keine Ahnung habe

Zitat

die bereits installierten Plugins von der Anleitung von cody belasse? Oder beisst sich der BigPatch-Test2 mit den Plugins eigentlich vom -Test1?

Nach meiner Erfahrung sollte man nach dem Patchen des VDR immer alle PLugins neu übersetzen

Grüße

Hi modul77,

nein, das Problem betrifft beide Bigpatch für 1.3.44 (Test1 und Test2).
Wenn du Test2 verwendest kannst du auch das im neuen PIN Plugin 0.0.12 enthaltene Patch (vdr-1.3.44-with-bigpatch-test2.diff) anschließend anwenden, das behebt auch das Problem.

Das findest du hier:
http://www.jwendel.de/vdr

Grüße Horchi

HI,

die neue Version 0.0.12, welche auch die Fixes zu den oben gemeldeten Fehlern beinhaltet, ist nun fertig:
http://www.jwendel.de/vdr

Das Patch hat sich geändert, daher neu Patchen und anschließend alles neu übersetzten.
Auch die Hinweise zum Patch im README beachten.

Die Änderungen:

* #12 20.03.06,  change: now using aux field in timer config patch
 *                        bugfix: autoProtectionMode will now restored from config
 *                                (Bug reported by rookie1, thanks!)
 *                        bugfix: autoProtectionMode now working even with vdr 1.3.44
 *                                (Bug reported by rookie1, thanks!)
 * #11 26.02.06,  bugfix: create missing config directory at startup.
 *                        bugfix: keys 1-5 now working in the pin menu.
 *                        added: hungary translations (thanks to Albert Papp!)
 *                        change: silend skip of channels works now again 
 *                               (fixed problems due to changes of VDR 1.3.40)
 * #10 28.01.06,  added regular expressions for brodcasts locks.
 *                       added russian translations (appropriated by Monchenko Vladimir, thanks!)
 *                        bugfix: only 3 chars of pin in setup menu (reported by Monchenko Vladimir, thanks!)

Grüße Horchi

HiJRx,

ich konnte das Problem hier so leider nicht nachvollziehen. Wenn ich von einem geschützen Kanal mit aktivem Kinderschutz via. Timer aufzeichne funktioniert die Aufnahme. Man kann sogar während der Aufnahme nicht zu eben diesem Kanal wechseln.
Oder habe ich dich falsch verstanden?

Hochi

liegt an dem PIN-Patch welches im Bigpatch enthalten ist (habe ich verbochen).
Wenn du die beiden folgenden Funktionen in timers.conf wie unten änderst und dev vdr neu übersetzt sollte das Problem behoben sein:

cString cTimer::ToText(bool UseChannelID)
{
  char *buffer;
  char *p;
  strreplace(file, ':', '|');


  // PIN PATCH
  char* tmp = 0;
  if (fskProtection && (!aux || !strstr(aux, "<pin-plugin><protected>yes</protected></pin-plugin>")))
  {
     if (aux) { tmp = strdup(aux); free(aux); }
     asprintf(&aux,"%s<pin-plugin><protected>yes</protected></pin-plugin>", tmp ? tmp : "");
  }
  else if (!fskProtection && aux && (p=strstr(aux, "<pin-plugin><protected>yes</protected></pin-plugin>")))
  {
     asprintf(&tmp, "%.*s%s", p-aux, aux, p+strlen("<pin-plugin><protected>yes</protected></pin-plugin>"));
     free(aux);
     aux = strdup(tmp);
  }
  if (tmp) free(tmp);
  asprintf(&buffer, "%u:%s:%s:%04d:%04d:%d:%d:%s:%s\n", flags, UseChannelID ? *Channel()->GetChannelID().ToString() : *itoa(Channel()->Number()), *PrintDay(day, weekdays), start, stop, priority, lifetime, file, aux ? aux : "");
  strreplace(file, '|', ':');
  return cString(buffer, true);
}




bool cTimer::Parse(const char *s)
{
  char *channelbuffer = NULL;
  char *daybuffer = NULL;
  char *filebuffer = NULL;
  free(aux);
  aux = NULL;
  //XXX Apparently sscanf() doesn't work correctly if the last %a argument
  //XXX results in an empty string (this first occured when the EIT gathering
  //XXX was put into a separate thread - don't know why this happens...
  //XXX As a cure we copy the original string and add a blank.
  //XXX If anybody can shed some light on why sscanf() failes here, I'd love
  //XXX to hear about that!
  char *s2 = NULL;
  int l2 = strlen(s);
  while (l2 > 0 && isspace(s[l2 - 1]))
        l2--;
  if (s[l2 - 1] == ':') {
     s2 = MALLOC(char, l2 + 3);
     strcat(strn0cpy(s2, s, l2 + 1), " \n");
     s = s2;
     }
  bool result = false;
  if (8 <= sscanf(s, "%u :%a[^:]:%a[^:]:%d :%d :%d :%d :%a[^:\n]:%a[^\n]", &flags, &channelbuffer, &daybuffer, &start, &stop, &priority, &lifetime, &filebuffer, &aux)) {
     ClrFlags(tfRecording);
     if (aux && !*skipspace(aux)) {
        free(aux);
        aux = NULL;
        }
     //TODO add more plausibility checks
     result = ParseDay(daybuffer, day, weekdays);
     strn0cpy(file, filebuffer, MaxFileName);
     strreplace(file, '|', ':');
     if (isnumber(channelbuffer))
        channel = Channels.GetByNumber(atoi(channelbuffer));
     else
        channel = Channels.GetByChannelID(tChannelID::FromString(channelbuffer), true, true);
     if (!channel) {
        esyslog("ERROR: channel %s not defined", channelbuffer);
        result = false;
        }
     }
  fskProtection = aux && strstr(aux, "<pin-plugin><protected>yes</protected></pin-plugin>");  // PIN PATCH
  free(channelbuffer);
  free(daybuffer);
  free(filebuffer);
  free(s2);
  return result;
}

Grüße Horchi

Hi rookie1,

> Was bedeutet eigentlich intelligent ?

intelligent bedeutet, dass die Aufnahme autom. geschützt wird, wenn entweder die aufgenommene Sendung und/oder der aufgenommene Sender zur Aufnahmezeit gesperrt war.

> habe folgendes Problem wenn ich mein Aufnahmeschutz auf "immer" stelle und dann
> neustarte ist es wieder auf intelligent.

stimmt, kann ich nachvollziehen, ist nun behoben.

> Nach Umstellung auf immer ohne neustart wird trotzdem kein Aufnahmeschutz erstellt,
> muss es also von Hand einschalten

auch das konnte ich nachvollziehen, da hat sich in einer der letzten VDR Versionen an der timers.c etwas geändert. Das war mir bislang noch nicht aufgefallen, danke für den Hinweis. Leider musste ich für den Bugfix auch das Patch anpassen (ist gerade geschehen). Werde es bald hochladen.

Als Workaround kann man in der Timer Konfiguration (via osd) den Timer so konfigurieren, dass die Aufnahme gesperrt wird.

Horchi