[Announce] epgsearch-0.9.23

winni · 20. November 2007

Hi,

das mit dem ext-Patch bezog sich auf rdnzl

Danke für die Ausgabe. Ist eigentlich klar, dass es damit nicht mehr gehen kann. Der Patch ändert ja auch was in der i18n.c, die es aber so seit 1.5.7 nicht mehr wirklich gibt. Als schnelle Abhilfe also am besten einfach die i18n.c.orig verwenden bzw. den Teil aus dem Patch rauswerfen. Betrifft ja eh "nur" die Übersetzung.

Tschüss,

winni

zulu · 20. November 2007

Hi,

den Fehler von rdnzl kann ich bei mir reproduzieren.

Es scheint mit dem LIEMIKUUTIO zusammen zuhängen: [ANNOUNCE] VDR Extensions Patch v.39

Gruß
Marc

mbc · 20. November 2007

Zitat

Original von ronnykornexl

VDR

Diff

------------------------------------------------------------------------
- VDR - Di 20 Nov 2007 10:33:07 CET
------------------------------------------------------------------------
+++ ver : 1.5.12 ...
+++ cmd : make REMOTE=LIRC all plugins -C /usr/local/src/VDR ...
+++ opt : CXXFLAGS = -fPIC -g -O2 -Wall -Woverloaded-virtual -D__user= CFLAGS += -fPIC CXXFLAGS += -fPIC PREFIX = /usr/local SRCDIR = $(PREFIX)/src VDRDIR = $(SRCDIR)/VDR PKG_CONFIG_PATH = $(PREFIX)/lib/pkgconfig:/usr/lib/pkgconfig DVBDIR = /usr/src/linux DVBDIR = $(SRCDIR)/DVB LOCDIR = $(VDRDIR)/locale VIDEODIR = $(shell echo $${VIDEODIR:-/video0}) DEFINES += -D_GNU_SOURCE INCLUDES += -I$(DVBDIR)/include LIRC_DEVICE = /dev/lircd RCU_DEVICE = /dev/ttyS1 VFAT = 1 HAVE_PCREPOSIX = 1 HAVE_LIBTRE = 1 WITHOUT_EPGSEARCHONLY = 1 WITHOUT_CONFLICTCHECKONLY = 1 WITHOUT_QUICKSEARCH = 1 ...
          i18n.c:300: error: expected unqualified-id before ‘{’ token
          i18n.c:320: error: expected unqualified-id before ‘,’ token
          i18n.c:320: error: expected unqualified-id at end of input
          make: *** [i18n.o] Fehler 1

Hi Ronny

Das Problem hatte ich hier auch :

Error beim epgsearch-Plugin 0.9.23beta18 unter VDR 1.5.9 ?

Schau Dir mal die letzten Zeilen in der i18.n an ... da wird durch den Patch etwas hinzugefügt was da nicht hin darf ... einfac halles löschen und gut ist .... (zumindest kompilierts dann, probleme konnte ich dadurch nicht feststellen).

Zitat

{ "Timer commands",
"Befehle für Timer",
"Ukazi za termine",
"Timer comandi",
"",// "Nederlands"
"",// "Português"
"Commandes de programmation",
"Timer kommandoer",
"Ajastinkomennot",
"",// "Polski"
"Comandos de programacion",
"",// "ÅëëçíéêÜ", // Greek
"Timer kommandon",
"Comenzi timer",
"",// "Magyar"
"Ordres de programació",
"",// "ÀãááÚØÙ", // Russian
"Naredbe za termine",
"",// "Eesti"
"",// "Dansk"
},

Alles anzeigen

MFG
Marco

ronnykornexl · 22. November 2007

Nabend

Danke, hat dann geklappt, hätte ja auch mal selbst rein schauen können

Was mir noch aufgefallen ist (habe Sie ausdokummentiert), dennoch wurden alle Plugins erstellt.

Code

### uncomment one of these lines, if you don't want the addon epgsearchonly, conflictcheckonly
WITHOUT_EPGSEARCHONLY=1
WITHOUT_CONFLICTCHECKONLY=1
WITHOUT_QUICKSEARCH=1

libvdr-conflictcheckonly.so libvdr-epgsearchonly.so libvdr-epgsearch.so libvdr-quickepgsearch.so

LG Ronny

amair · 23. November 2007

Hallo winni!

Zum Thema "Keine Suchergebnisse anzeigen wenn eine Aufnahme abgespielt wird".
Kann es sein, dass da noch ein Bug drinnen ist?
Ich hatte letztens Fall, dass ich das Suchtimer-Update manuell gestartet habe, aber dass die Meldung, dass etwas gefunden wurde, nicht kam. Nur, dass die Suche durchegeführt wurde. Es wurde keine Aufnahme abgespielt. Das einzige - und das ist reproduzierbar - war, dass zwei Aufnahmen liefen und beide DVB-Karten beschäftigt waren.
Ist das ein Bug im epgsearch oder im VDR?

Gruß,
Andreas

winni · 23. November 2007

Hi Andreas,

hmm, komisch. Ich prüfe einfach, ob das primary device gerade im Replay-Modus ist.
Werd mir das nochmal angucken. Im Moment dauert das alles nur etwas, weil ich grad dabei bin, nen neuen VDR aufzusetzen.

Tschüss,

winni

viking · 23. November 2007

Hallo Winni,

habe mir die 0.9.24.beta10 installiert und die fuzzy-suche nach aufnhamen getestet. Sieht recht gut aus. Ich habe nur ein problem das ich ein verzeichnis "Test" habe wo ich alle möglich test-aufnahmen gespeichert habe. Von diesem verzeichnis kommt jedes mal ca. 20 ergebnisse, so das man den richtigen erst auf dem zweiten blick findet.

Kann man die "fuzzyness" irgendwo einstellen ? Oder wäre es möglich einzubauen das man irgendwo konfigurieren kann das verzeichnisse von der suche auszuschliessen sind ? z.b. /video/Test.

Einige davon habe ganz kurze namen kann es daran liegen das er sie findet ?

Danke

EDIT: gibt es in den 0.9.24.beta10 irgenwelche bugs die bekannt sind ? Sollte ich lieber eine neuere nehmen (wenn es einen gibt)

Gruß
Viking

winni · 23. November 2007

Hi viking,

die Suche nach Aufnahmen beachtet den Pfad mittlerweile nicht mehr. Nur noch den Titel der Aufnahme. Die Fuzzy-Suche selbst erlaubt dabei eine Abweichung von max. 10% der Länge des Titels oder des Suchbegriffs (je nach dem was kürzer ist), aber mindestens ein Zeichen.

Zitat

Einige davon habe ganz kurze namen kann es daran liegen das er sie findet ?

ja, wie gesagt, ein Zeichen Abweichung ist immer erlaubt.

Zitat

EDIT: gibt es in den 0.9.24.beta10 irgenwelche bugs die bekannt sind ? Augenzwinkern Sollte ich lieber eine neuere nehmen (wenn es einen gibt)

Aktuell wäre beta13. Bekannt ist mir bisher nix Die beta13 hat vorallem nen deutlichen Performance-Sprung beim Menüaufbau und dem Suchtimer-Update bekommen. Hier mal ein Danke an die Jungs von www.open7x0.org.

Tschüss,

winni

viking · 23. November 2007

Hallo Winni,

OK, dann teste ich mal die neue version.

Gruß
Viking

viking · 23. November 2007

HAllo,

läßt sich leider nicht kompilieren :

Code

g++ -Wall -O2 -Woverloaded-virtual -Wno-format-y2k -fPIC -c -DUSE_CMDSUBMENU -DU
SE_CUTTERLIMIT -DUSE_CUTTERQUEUE -DUSE_DDEPGENTRY -DUSE_DVBSETUP -DUSE_DVDARCHIV
E -DUSE_DVLVIDPREFER -DUSE_GRAPHTFT -DUSE_JUMPPLAY -DUSE_LIEMIKUUTIO -DUSE_LIVEB
UFFER -DUSE_LNBSHARE -DUSE_MAINMENUHOOKS -DUSE_OSDMAXITEMS -DUSE_PINPLUGIN -DUSE
_PLUGINMISSING -DUSE_SETUP -DUSE_SORTRECORDS -DUSE_TIMERCMD -DUSE_TIMERINFO -DUS
E_WAREAGLEICON -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"epgsearch"' -I/usr/local/src/D
VB/include -I../../../include -I/usr/local/src/DVB/include menu_event.c
menu_event.c: In member function 'virtual void cMenuEventSearch::Display()':
menu_event.c:130: error: 'MsgOsdSetEvent' is not a member of 'cStatus'
make[1]: *** [menu_event.o] Error 1

System siehe signatur.

Gruß
Viking

winni · 23. November 2007

Hi,

das liegt an einer Erweiterung wg. GraphTFT, die im nächsten ext-patch drin sein wird. Kommentier die Funktion in menu_event.c am besten ganz aus. Also so:

Code

void cMenuEventSearch::Display(void)
{
  cOsdMenu::Display();
//#ifdef USE_GRAPHTFT
//  cStatus::MsgOsdSetEvent(event);
//#endif
  if (event)
  {
      DisplayMenu()->SetEvent(event);
      cStatus::MsgOsdTextItem(event->Description());
  }
}

Alles anzeigen

Tschüss,

winni

winni · 25. November 2007

Hi zulu,

Zitat

den Fehler von rdnzl kann ich bei mir reproduzieren.

mit dem ext-Patch kann ich das ganze nachvollziehen. Ich hab jetzt auch mal ein paar Stunden rumdebuggt. Wenn LIEMIKUUTIO im ext-Patch aktiv ist, hab ich den Absturz. Allerdings an einer sehr seltsamen Stelle, nämlich bei einem "tr", also einer Übersetzung. Im Plain-VDR funktionierts dagegen. Seltsamerweise aber auch, wenn ich nur den LIEMIKUUTIO-Patch direkt gegen Plain-VDR laufen lasse, also ohne ext-Patch. Irgendwie steh ich aufm Schlauch

Tschüss,

winni

zulu · 26. November 2007

Hi winni,

der LIEMIKUUTIO im Extensions Patch ist eine erweiterte Version des liemikuutio-1.16
Allerdings ist der Code in osdbase.c und osdbase.h original aus dem liemikuutio übernommen und wenn ich den Teil rausnehme stützt nichts mehr ab.

Bei meinen letzten Versuchen mit vdr 1.4.7 und 1.5.12 habe ich erst alle Patche abgeschaltet - kein Absturz. Dann LIEMIKUUTIO angeschaltet, neu übersetzt und der VDR stürzt im Setup vom conflictcheckonly ab:

Code

*** glibc detected *** /usr/bin/vdr: malloc(): memory corruption: 0x08625090 ***
======= Backtrace: =========
/lib/i686/cmov/libc.so.6[0xb7cd2036]
/lib/i686/cmov/libc.so.6(__libc_malloc+0x8d)[0xb7cd39ad]
/lib/i686/cmov/libc.so.6[0xb7c8e1aa]
/lib/i686/cmov/libc.so.6[0xb7c8c5ef]
/lib/i686/cmov/libc.so.6[0xb7c8bfbe]
/lib/i686/cmov/libc.so.6(dcgettext+0x43)[0xb7c8aeb3]
/lib/i686/cmov/libc.so.6(gettext+0x21)[0xb7c8af11]
/usr/bin/vdr(_Z13I18nTranslatePKcS0_+0x58)[0x80bfcd8]
/usr/lib/vdr/plugins/libvdr-conflictcheckonly.so.1.5.12(_ZN26cMainMenuShortcutSetupPageC1EPKcS1_Pi+0x5b)[0xb79010fb]
/usr/lib/vdr/plugins/libvdr-conflictcheckonly.so.1.5.12(_ZN17cMainMenuShortcut9SetupMenuEv+0x56)[0xb7901206]
/usr/bin/vdr(_ZN17cMenuSetupPlugins10ProcessKeyE5eKeys+0x95)[0x80cdbe5]
/usr/bin/vdr(_ZN8cOsdMenu10ProcessKeyE5eKeys+0x28)[0x80e2db8]
/usr/bin/vdr(_ZN10cMenuSetup10ProcessKeyE5eKeys+0x28)[0x80dbf18]
/usr/bin/vdr(_ZN8cOsdMenu10ProcessKeyE5eKeys+0x28)[0x80e2db8]
/usr/bin/vdr(_ZN9cMenuMain10ProcessKeyE5eKeys+0x38)[0x80cf368]
/usr/bin/vdr(main+0x1b44)[0x811f424]
/lib/i686/cmov/libc.so.6(__libc_start_main+0xe0)[0xb7c7c450]
/usr/bin/vdr(__gxx_personality_v0+0x191)[0x8094581]
======= Memory map: ========
08048000-08161000 r-xp 00000000 03:02 779013     /usr/bin/vdr
08161000-08163000 rw-p 00118000 03:02 779013     /usr/bin/vdr
08163000-086b0000 rw-p 08163000 00:00 0          [heap]
af700000-af721000 rw-p af700000 00:00 0
af721000-af800000 ---p af721000 00:00 0
....

Alles anzeigen

Gruß
Marc

winni · 26. November 2007

Hi Marc,

Zitat

Allerdings ist der Code in osdbase.c und osdbase.h original aus dem liemikuutio übernommen und wenn ich den Teil rausnehme stützt nichts mehr ab.

das ist das seltsame. Ich hab das im ext-Thread gelesen und probiert. Hab aber trotzdem noch die Abstürze. Erst wenn ich den LIEMIKUUTIO ganz aus ext rausnehme, läuft es ohne Probleme.

Ich werd dran bleiben

Tschüss,

winni

zulu · 26. November 2007

Wirklich seltsam, wenn ich in osdbase.c und osdbase.h alle "#ifdef USE_LIEMIKUUTIO" zu "#ifdef _USE_LIEMIKUUTIO" mache und neu übersetze habe ich definitiv keine Abstürze.

Gruß
Marc

winni · 26. November 2007

ah, in osdbase.h hatte ich bisher nix gemacht, nur im c-file. Werd das nochmal probiern.

Tschüss,

winni

viking · 27. November 2007

Hallo Winni,

das mit dem auskommentieren + kompilieren hat geklappt Mittlerweile bin ich auf die ext40'er gegagne, so das es auch ohne geht.

Zitat

Originally posted by winni
die Suche nach Aufnahmen beachtet den Pfad mittlerweile nicht mehr. Nur noch den Titel der Aufnahme. Die Fuzzy-Suche selbst erlaubt dabei eine Abweichung von max. 10% der Länge des Titels oder des Suchbegriffs (je nach dem was kürzer ist), aber mindestens ein Zeichen.

habe jetzt die neue version getestet und es war das selbe ergebnis !?

Dies ist jetzt kein reales beispiel, wiel ich nicht mehr erinnern kann was ich ausprobiert habe und es scheinbar egal ist wonach ich suche - es kommt immer zu viel. Also wenn ich z.b. in epg gehe (übersicht ARD) und dann die "5" drücke auf "Tagesschau" - dann findet er dann z.b. :
Test/Test2/%BM

und diverse andere aufnahmen in dem verz. mit kurzen namen.
Das weicht ja doch in der länge mehr als 10% ab !?

Gruß
Viking

winni · 27. November 2007

Hi viking,

Zitat

habe jetzt die neue version getestet und es war das selbe ergebnis !?

das war ein Mißverständnis. Geändert hat sich in der beta13 dazu nichts. Wollt nur erwähnen, dass es die beta13 gibt.

Ich merk aber auch grad, dass mit dem fuzzy-Suchen in den Aufnahmen etwas noch nicht paßt. Werd da noch nachbessern.

Tschüss,

winni

mase · 27. November 2007

Die Fuzzy-Suche liefert bei mir Ergebnisse, die rein gar nichts gemeinsam
mit der gesuchten Sendung haben. Irgendwie kommt es mich so vor, als
bekäme ich immer dieselben Ergebnisse, egal, welche Sendung ich suche.
Hab ich was übersehen?

winni · 27. November 2007

Hi,

mase und viking:

Bitte mal mit beta14 testen, damit sollte die fuzzy-Suche in den Aufnahmen nun klappen.

Ebenfalls sollten die Abstürze im Setup der Addon-Plugins bei Verwendung des ext-Patches nun weg sein.

Tschüss,

winni

[Announce] epgsearch-0.9.23

Jetzt mitmachen!

Teilen