Posts by nvertigo

    Wenn ich:

    Code
    1. mysql -D epg2vdr -e 'select * from series_media where series_id = 78817;'


    ausführe, bekomme ich seitenweise '-'-ZeiChen, gefolgt von '1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c'.
    Habe ich da etwas falsch verstanden?

    Sortiert nach virtueller Speichergröße:

    Code
    1. top - 14:16:28 up 19 days, 18:53, 10 users, load average: 0.62, 0.61, 0.65 Tasks: 381 total, 1 running, 380 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.4 us, 0.6 sy, 0.1 ni, 98.7 id, 0.1 wa, 0.1 hi, 0.0 si, 0.0 st KiB Mem: 16391768 total, 15327416 used, 1064352 free, 1373708 buffers KiB Swap: 33554428 total, 3100220 used, 30454208 free, 9235840 cached
    2. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
    3. 3254 root 20 0 4187172 5804 1992 S 0.0 0.0 0:03.02 console-kit-dae 23139 root 20 0 4181236 589596 44424 S 6.0 3.6 4:01.86 vdr
    4. 15481 mysql 20 0 892480 75892 5676 S 0.3 0.5 25:03.03 mysqld
    5. 3724 root 20 0 664196 1520 1164 S 0.0 0.0 0:59.39 nscd 3152 apache 20 0 640868 396 280 S 0.0 0.0 0:00.00 apache2
    6. 3154 apache 20 0 640868 400 280 S 0.0 0.0 0:00.01 apache2
    7. 3325 polkitd 20 0 547928 3408 1956 S 0.0 0.0 0:02.64 polkitd 15466 root 20 0 462724 8664 1912 S 0.0 0.1 15:16.47 udisksd 9924 root 20 0 268304 4428 1836 S 0.0 0.0 0:01.94 upowerd 3099 root 20 0 231164 1028 972 S 0.0 0.0 0:29.75 apache2 3101 apache 20 0 212604 408 396 S 0.0 0.0 0:00.00 apache2 10004 root 20 0 189976 3232 2132 S 0.0 0.0 2:08.26 udisks-daemon


    Sortiert nach residenter Speichergröße:

    Code
    1. top - 14:19:35 up 19 days, 18:56, 10 users, load average: 0.47, 0.57, 0.63 Tasks: 382 total, 2 running, 380 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.4 us, 0.5 sy, 0.1 ni, 98.9 id, 0.0 wa, 0.1 hi, 0.0 si, 0.0 st
    2. KiB Mem: 16391768 total, 15328168 used, 1063600 free, 1373716 buffers KiB Swap: 33554428 total, 3100220 used, 30454208 free, 9236360 cached
    3. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
    4. 23139 root 20 0 4181236 589852 44424 S 5.3 3.6 4:14.29 vdr
    5. 15481 mysql 20 0 892480 75892 5676 S 0.0 0.5 25:04.09 mysqld 17866 root 19 -1 157832 52704 17512 S 0.0 0.3 0:10.06 X
    6. 17903 root 20 0 92956 25716 3776 S 0.0 0.2 0:00.53 gg_launcher.pl
    7. 27470 root 20 0 182628 25292 5476 S 0.0 0.2 1:19.20 epgd 15466 root 20 0 462724 8664 1912 S 0.0 0.1 15:16.47 udisksd 3254 root 20 0 4187172 5804 1992 S 0.0 0.0 0:03.02 console-kit-dae 16212 root 20 0 133680 4532 3352 S 0.0 0.0 0:00.39 sshd 9924 root 20 0 268304 4428 1836 S 0.0 0.0 0:01.94 upowerd 861 root 20 0 100376 4112 3208 S 0.0 0.0 0:00.02 sshd
    8. 23260 root 20 0 17944 4080 1624 S 0.0 0.0 0:01.43 bash
    9. 2444 root 20 0 61784 3772 1872 S 0.0 0.0 7:15.49 syslog-ng


    Um bei multi-core builds etwas mehr Dampf zu haben, habe ich das hier (seit ca. 18 Monaten):

    Code
    1. adler VDR # grep proc/sys/vm /etc/local.d/*
    2. echo 90 >/proc/sys/vm/dirty_ratio #= 90 (% per process, default = 10)
    3. echo 80 >/proc/sys/vm/dirty_background_ratio #= 80 (% system-wide, default = 5)
    4. echo 6000 >/proc/sys/vm/dirty_expire_centisecs #= 6000 (60s, default = 30s)
    5. echo 4000 >/proc/sys/vm/dirty_writeback_centisecs #= 4000 (40s, default = 5s)
    6. adler VDR # cat /proc/sys/vm/swappiness
    7. 60


    EDIT: sehe gerade, dass meine Sig nicht mehr stimmt. Ändere gleich

    Code
    1. free
    2. total used free shared buffers cached
    3. Mem: 16391768 16126984 264784 0 1372952 9480780
    4. -/+ buffers/cache: 5273252 11118516
    5. Swap: 33554428 3099176 30455252


    Plus/minus ist das recht typisch. Zumindest zum Zeitpunkt des letzten Absturzes lief auch kein emerge oder android build, oder ähnliches, dass Speicher benötigt. Imagemagick ist 6.8.8.10, das verwende ich seit dem 10.4. Die drei Abstürze habe in den letzten beiden Tagen stattgefunden.


    Gruß, Ingo


    P.S.: natürlich tut mir der Fehler jetzt gerade (mit debug im vdr) nicht den Gefallen aufzutreten... :(

    Hatte folgendes jetzt drei mal. Zufällig, nicht reproduzierbar - wenn es vorkommt, dann nach dem Umschalten:


    Leider hatte ich den vdr ohne debuging übersetzt (jetzt läuft er mit debugging symbols - wenns wieder vorkommt, wirds ausführlicher: mit bt).


    Gruß, Ingo

    Nein ich habe für serien kein einziges fanart*, poster*, banner* im FS. Wie kann ich gucken, ob die in der DB da wäen? (für movies habe ich fanart, banner, poster im FS) Ich probier seit gestern wirklich alles aus - wie geschrieben: mit/ohne userexit.sql, mit original channelmap.conf (nur die aus PLUGINS/tvm/configs an die aus configs gecattet), mir gehen die Ideen aus, wo ich noch debuggen kann. Welche Infos brauchst Du?

    Ich bekomme keine Bildergalrie bei Serien. Besetzungsbilder sind da. Bilder in TVDB Info sind auch da. Bildergalerie ist leer, obwohl Skinnopacity versucht zu laden. Im FS habe ich bei Serien kein poster*, banner*, fanart*. Habe die ganze DB gelöscht und erneuert und alles neu geholt. Gleiches Phänomen. Habe das alles nochmal ohne userexit.sql gemacht: Gleiches Phänomen.


    Ich vermisse auch bei alten Aufnahmen, die mehr als ein Bild haben, die Anzeige dieser.


    Code
    1. opacity: ERROR: access to unknown config value numAdditionalEPGPictures


    Außerdem habe ich das Gefühl, dass das Mischen so zu einem 10tel funktiniert:


    Leider kann ich hier durch 3g nicht so testen,wie ich will, wundere mich auch, dass das mit der Bildrgalerie nur hier auftritt (liegts vieleicht doch an meiner IP-Anbindung?), aber vor den letzten Änderungen lief es runder... :(


    Stimmt schon weitgehend mit den Dateien überein. Aber wie gesagt, hier zickt einiges, auch das Mischen. Ich lasse jetzt den vdr ohne epg2vdr und scraper2vdr laufen, lösche die epg2vdr db, lege sie neu an, kaufe Volumen und starte den epgd neu... :(


    Danke für Eure Hilfe.

    Nö, dauert bei mir 4 bis 6 h. Aber ich werde wohl nicht umhin kommen - hier mischt es auch nicht mehr:

    Aber da du es jetzt eh kaputt gemacht hast, kill doch einfach nochmal alles komplett und starte "from scratch"...


    ...Sätze, die man bei 5GB Volumen-Begrenzung nicht lesen will... :(


    Nur damit wir uns richtig verstehen - Du meinst:

    Code
    1. /etc/init.d/vdr stop
    2. /etc/init.d/epgd stop
    3. epgd-tool -del-db
    4. epgd-tool -new-db
    5. /etc/init.d/epgd start
    6. rm -r [scraper-verzeichnis,epgdata,epgimages]
    7. /etc/init.d/vdr start

    Ingo : lösche doch nochmal das komplette Bilderverzeichnis /var/vdr/scraper2vdr-images und schaue, ob beim Naustart des VDR alle Bilder neu kopiert werden. Das dauert ein bisschen, schau mal ins Log, da steht drinn was das Plugin gerade so treibt...mir ist ein solcher Effekt noch nicht aufgefallen.


    Ich gehe davon aus, dass das bei allen Bildern so ist? Oder nur vereinzelt?


    Ciao Louis


    Du erwartest jetzt bitte keine Aussage über ca. 250 Sender in channelmap.conf und 14 Tage im voraus, die "alle" und "keine einzige" enthält?


    Meine folgenden Aussagen beziehen sich auf meine Aufnahmen: Alle Serien, die "Bildergalerie" anzeigen haben keine Bilder dort, erzeugen aber die Fehlermeldungen über den Versuch Bilder zu laden, wenn ich in die Bildergalerie gehe (BTW: tolle Idee die Detailansicht aufzubrechen!). Alle Filme funktionieren korrekt!


    Nach Stichproben im epg verhält es sich genauso - aber da kann ich keine flächendeckende Aussage aabgeben.


    Das Löschen des Scraper-Verzeichnisses habe ich schon ausprobiert (mehrfach), bevor ich über 3g neu gescrapt habe. Und ebenso vor dem neu-Scrapen selbst.


    Ich habe dropall ohne epg-images ausgeführt, und folgendes gemachT:

    Code
    1. mysql -u epg2vdr -pepg -Depg2vdr -e 'drop table series;'
    2. mysql -u epg2vdr -pepg -Depg2vdr -e 'drop table series_episode;'
    3. mysql -u epg2vdr -pepg -Depg2vdr -e 'drop table series_actor;'
    4. mysql -u epg2vdr -pepg -Depg2vdr -e 'drop table series_media;'
    5. mysql -u epg2vdr -pepg -Depg2vdr -e 'drop table movie;'
    6. mysql -u epg2vdr -pepg -Depg2vdr -e 'drop table movie_actors;'
    7. mysql -u epg2vdr -pepg -Depg2vdr -e 'drop table movie_actor;'
    8. mysql -u epg2vdr -pepg -Depg2vdr -e 'drop table movie_media;'
    9. mysql -u epg2vdr -pepg -Depg2vdr -e 'drop table recordings;'


    Danach waren im mysql/epg2vdr die *.ibd Dateien weg - aber einige *.frm Dateien blieben übrig. Steht da vieleicht noch Schrunz mit veralteten ids drin?


    Gruß, Ingo

    Disclaimer: dies ist keine Aufforderung an irgendjemanden eine Diskussion um das einzig wahre Buildsystem, inkl. der einzig wahren Anwendung von Makefiles zu beginnen. Es ist einfach nur eine aus der Hüfte geschossene Idee.


    Könnte man libhorchi nicht dynamisch als libhorchi.so bauen und einen entsprechenden pkgconfig Eintrag installieren? In epg2vdr und scraper2vdr wird dann im Makefile via pkgconfig der Pfad zur dynamischen libhorchi angezogen.


    Gruß, Ingo

    Herzlichen Dank an Euch drei: nicht nur Eure Projekte, auch Euer Support ist genial.


    Hier baut und funktioniert epgd, epg2vdr und scraper2vdr. Das tvm-plugin holt Daten, und die landen auch prima nach der Episodenaufbereitung durch den userexit Aufruf im vdr. Scraper2vdr scrapt sich einen Wolf und holt sich ca. 3,3 GB Daten (habe die scraper tables mal sicherheitshalber gedropt).


    Natürlich kommt jetzt ein ABER:
    Aber im skinnopacity sind die Bilder galerien leer, obwohl skinnopacity anscheinend die Information bekommt, das etwas da sein sollte:

    Code
    1. May 11 07:53:00 adler vdr: [31278] nopacity: trying to load: /var/vdr/scraper2vdr-images/series/76156/poster1.jpg
    2. May 11 07:53:00 adler vdr: [31278] nopacity: Magick Error: vdr: unable to open image `/var/vdr/scraper2vdr-images/series/76156/poster1.jpg': Datei oder Verzeichnis nicht gefunden @ error/blob.c/OpenBlob/2645 May 11 07:53:02 adler vdr: [31281] nopacity: trying to load: /var/vdr/scraper2vdr-images/series/76156/banner1.jpg May 11 07:53:02 adler vdr: [31281] nopacity: Magick Error: vdr: unable to open image `/var/vdr/scraper2vdr-images/series/76156/banner1.jpg': Datei oder Verzeichnis nicht gefunden @ error/blob.c/OpenBlob/2645 May 11 07:53:02 adler vdr: [31281] nopacity: trying to load: /var/vdr/scraper2vdr-images/series/76156/poster2.jpg May 11 07:53:02 adler vdr: [31281] nopacity: Magick Error: vdr: unable to open image `/var/vdr/scraper2vdr-images/series/76156/poster2.jpg': Datei oder Verzeichnis nicht gefunden @ error/blob.c/OpenBlob/2645 May 11 07:53:29 adler vdr: [31309] nopacity: trying to load: /var/vdr/scraper2vdr-images/series/76156/banner1.jpg May 11 07:53:29 adler vdr: [31309] nopacity: Magick Error: vdr: unable to open image `/var/vdr/scraper2vdr-images/series/76156/banner1.jpg': Datei oder Verzeichnis nicht gefunden @ error/blob.c/OpenBlob/2645 May 11 07:53:29 adler vdr: [31309] nopacity: trying to load: /var/vdr/scraper2vdr-images/series/76156/fanart1.jpg
    3. May 11 07:53:29 adler vdr: [31309] nopacity: Magick Error: vdr: unable to open image `/var/vdr/scraper2vdr-images/series/76156/fanart1.jpg': Datei oder Verzeichnis nicht gefunden @ error/blob.c/OpenBlob/2645 May 11 07:53:29 adler vdr: [31309] nopacity: trying to load: /var/vdr/scraper2vdr-images/series/76156/banner2.jpg
    4. May 11 07:53:29 adler vdr: [31309] nopacity: Magick Error: vdr: unable to open image `/var/vdr/scraper2vdr-images/series/76156/banner2.jpg': Datei oder Verzeichnis nicht gefunden @ error/blob.c/OpenBlob/2645 May 11 07:53:29 adler vdr: [31309] nopacity: trying to load: /var/vdr/scraper2vdr-images/series/76156/fanart2.jpg
    5. May 11 07:53:29 adler vdr: [31309] nopacity: Magick Error: vdr: unable to open image `/var/vdr/scraper2vdr-images/series/76156/fanart2.jpg': Datei oder Verzeichnis nicht gefunden @ error/blob.c/OpenBlob/2645 May 11 07:53:29 adler vdr: [31309] nopacity: trying to load: /var/vdr/scraper2vdr-images/series/76156/banner3.jpg
    6. May 11 07:53:29 adler vdr: [31309] nopacity: Magick Error: vdr: unable to open image `/var/vdr/scraper2vdr-images/series/76156/banner3.jpg': Datei oder Verzeichnis nicht gefunden @ error/blob.c/OpenBlob/2645 May 11 07:53:29 adler vdr: [31309] nopacity: trying to load: /var/vdr/scraper2vdr-images/series/76156/fanart3.jpg
    7. May 11 07:53:29 adler vdr: [31309] nopacity: Magick Error: vdr: unable to open image `/var/vdr/scraper2vdr-images/series/76156/fanart3.jpg': Datei oder Verzeichnis nicht gefunden @ error/blob.c/OpenBlob/2645 May 11 07:53:29 adler vdr: [31309] nopacity: trying to load: /var/vdr/scraper2vdr-images/series/76156/poster1.jpg
    8. May 11 07:53:29 adler vdr: [31309] nopacity: Magick Error: vdr: unable to open image `/var/vdr/scraper2vdr-images/series/76156/poster1.jpg': Datei oder Verzeichnis nicht gefunden @ error/blob.c/OpenBlob/2645 May 11 07:53:29 adler vdr: [31309] nopacity: trying to load: /var/vdr/scraper2vdr-images/series/76156/poster2.jpg
    9. May 11 07:53:29 adler vdr: [31309] nopacity: Magick Error: vdr: unable to open image `/var/vdr/scraper2vdr-images/series/76156/poster2.jpg': Datei oder Verzeichnis nicht gefunden @ error/blob.c/OpenBlob/2645 May 11 07:53:29 adler vdr: [31309] nopacity: trying to load: /var/vdr/scraper2vdr-images/series/76156/poster3.jpg
    10. May 11 07:53:29 adler vdr: [31309] nopacity: Magick Error: vdr: unable to open image `/var/vdr/scraper2vdr-images/series/76156/poster3.jpg': Datei oder Verzeichnis nicht gefunden @ error/blob.c/OpenBlob/264


    Außerdem ist mir aufgefallen, dass in der mysql offenbar mehr Bilder-Daten sind, als durch den scraper im FS ankommen:

    Code
    1. du -sm /var/vdr/scraper2vdr-images/ ./series_media.* ./movie_media.*
    2. 1692 /var/vdr/scraper2vdr-images/
    3. 1 ./series_media.frm
    4. 2085 ./series_media.ibd
    5. 1 ./movie_media.frm
    6. 1169 ./movie_media.ibd


    Meine IP-Anbindung läuft über 3g, aber das Daten holen scheint ja zu funktinieren.


    Mit den Easteregg commits von vor ca. 2 Wochen hatte es funktiniert - da hatte ich auch ca. 3,5 GB Daten im FS.


    Gruß, Ingo

    Doch. Aber sie landen nich im linker-Aufruf!?!

    Code
    1. g++ -ggdb -O0 -fPIC -Wreturn-type -Wformat -pedantic -Wunused-variable -Wunused-label -Wunused-value -Wunused-function -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/mysql -rdynamic main.o update.o plugin.o channelmap.o series.o svdrpclient.o levenshtein.o episode.o tvdbmanager.o moviedbmanager.o tools/curlfuncs.o tools/fuzzy.o tools/stringhelpers.o scraper/thetvdbscraper/thetvdbscraper.o scraper/thetvdbscraper/tvdbseries.o scraper/thetvdbscraper/tvdbmirrors.o scraper/thetvdbscraper/tvdbmedia.o scraper/thetvdbscraper/tvdbactor.o scraper/thetvdbscraper/tvdbepisode.o scraper/themoviedbscraper/themoviedbscraper.o scraper/themoviedbscraper/moviedbmovie.o scraper/themoviedbscraper/moviedbactor.o -L./lib -lhorchi -lcurl -lxml2 -lz -lm -ldl -L/usr/lib64 -lxslt -lxml2 -lz -ldl -lm -lrt -lexslt -lrt -lz -larchive -ldl -lcrypto -luuid -ljansson -Wl,-O1 -Wl,--as-needed -rdynamic -L/usr/lib64/mysql -lmysqlclient -L/usr//lib64 -lz -lcrypt -lnsl -lm -L/usr/lib64/ -lssl -lcrypto -o epgd
    2. /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../x86_64-pc-linux-gnu/bin/ld: ./lib/libhorchi.a(common.o): undefined reference to symbol 'pthread_mutexattr_settype@@GLIBC_2.2.5'
    3. /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../x86_64-pc-linux-gnu/bin/ld: note: 'pthread_mutexattr_settype@@GLIBC_2.2.5' is defined in DSO /lib64/libpthread.so.0 so try adding it to the linker command line
    4. /lib64/libpthread.so.0: could not read symbols: Invalid operation
    5. collect2: Fehler: ld gab 1 als Ende-Status zurck
    6. make: *** [epgd] Fehler 1
    7. ingo@adler /usr/local/src/epgd $ mysql_config --libs_r
    8. -Wl,-O1 -Wl,--as-needed -rdynamic -L/usr/lib64/mysql -lmysqlclient_r -L/usr//lib64 -lz -lpthread -lcrypt -lnsl -lm -lpthread -L/usr/lib64/ -lssl -lcrypto

    Jörg :


    Mit meinem zweiten Patch läuft epgd mit tvm-plugin stabil auf MEINEM System. Epgdata-plugin lädt, aber ich benutze es nicht - dafür mußte ich USELIBARCHIVE erzwingen - wahrscheinlich hast Du Dir beim ifdef etwas gedacht, mein patch prüft nix, sondern setzt nur -DUSELIBARCHIV. Auf anderen Systemen mag das zu Problemen führen.


    Ich fand es hilfreich das make lib in lib ohne -s aufzurufen.


    Hoffe es hilft Dir etwas.


    Gruß, Ingo