wo du gerade son Lauf hast und wo deine Frau ja eh mit testen beschäftigt ist...... magst du son ähnlichen Patch nicht für epgsearch machen? 
Sicher ich weiß schon man kann eine abgekupferte epgsearch Ansicht in remotetimers aktivieren, die hat aber so viele Einschränkungen, insbesondere das fehlende Favoritenmenu und die fehlenden Graphtft Ansichten das es eher ein no-go ist ....
Ansonsten teste ich deinen Patch später gern
Christian
Hi,
Bei mir gibt es einen kleinen Bug zusammen mit dem DVD Plugin: In der Infoleiste (Progressbar) gibt es Grafikfehler, sie wird nicht sauber dargestellt. Auf Wunsch kann ich nen Screenshot posten.
Gruß maz
voila - ist etwas schwer zu erkennen. Es gibt Grafikfehler zwischen der oberen Schrift und der Progressbar, und die Buttons (Play, Pause etc) werden nicht richtig dargestellt.
Ok, da werden die entsprechenden Pixmaps nicht transparent gefüllt...kann ich mal nachziehen. Machst du bitte einen Bugreport mit dem Link zu deinem Posting auf vdrdeveloper dafür auf?
Alternativ könnte das DVD Plugin das "DisplayReplay" auch vollständig aufrufen Kannst ja mal den Autor anfragen, ob er das nachziehen will...
Ciao Louis
Ich habe nach wie vor noch das Problem, dass im ausführlichen EPG der Aufzeichnungen ab und zu nur gähnende Leere angezeigt wird, obwohl EPG-Daten laut Kurzinfo vorhanden ist.
Gruß
iNOB
Hatte folgendes jetzt drei mal. Zufällig, nicht reproduzierbar - wenn es vorkommt, dann nach dem Umschalten:
May 12 11:48:26 adler vdr: [14495] dbus2vdr: de.tvdr.vdr.remote.HitKey: get key 'Channel+'
May 12 11:48:26 adler vdr: [30949] nopacity: trying to load: /var/vdr/scraper2vdr-images/movies/82731/poster.jpg
May 12 11:48:26 adler vdr: [30949] nopacity: /var/vdr/scraper2vdr-images/movies/82731/poster.jpg sucessfully loaded
May 12 11:48:26 adler gen2vdr: terminate called after throwing an instance of 'Magick::ErrorResourceLimit'
May 12 11:48:26 adler gen2vdr: what(): vdr: memory allocation failed `/var/vdr/scraper2vdr-images/movies/82731/poster.jpg' @ error/resize.c/SampleImage/3166
May 12 11:48:26 adler gen2vdr: Mai 12 11:20:47.210 [general.info] VDR dvbsddevice plugin loaded as subplugin
May 12 11:48:26 adler gen2vdr: Mai 12 11:20:47.210 [general.info] VDR dvbhddevice plugin loaded as subplugin
May 12 11:48:26 adler gen2vdr: Mai 12 11:20:47.211 [general.debug] using new 1.7.11+ capture code
May 12 11:48:26 adler gen2vdr: vdr-radio: arg files-dir = /etc/vdr/plugins/radio
May 12 11:48:26 adler gen2vdr: vdr-radio: arg data-dir = /tmp/vdr-radio
May 12 11:48:26 adler gen2vdr: vdr-radio: Radio-Plugin Backgr.Image/RDS-Text starts...
May 12 11:48:27 adler gen2vdr: Debug2
May 12 11:48:27 adler gen2vdr: VDR wurde beendet - RC: 0
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
Wie voll ist der Speicher denn bei dir?
Gerald
free
total used free shared buffers cached
Mem: 16391768 16126984 264784 0 1372952 9480780
-/+ buffers/cache: 5273252 11118516
Swap: 33554428 3099176 30455252Plus/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... 
Dass er bei 16GB trotzdem schon mal swapped finde ich irgendwie ziemlich heftig. Wer verbraucht denn da so viel?
Gerald
Ein "brunch manta" im cyanogenmod-Verzeichnis. Aber wie gesagt, das war nicht während des vdr-Absturzes. Und wenn Du Dir das bereinigte free ansiehst ist alles grün.
Dass er bei 16GB trotzdem schon mal swapped finde ich irgendwie ziemlich heftig.
Wie ist denn die swappiness eingestellt?
Sortiert nach virtueller Speichergröße:
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
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
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
15481 mysql 20 0 892480 75892 5676 S 0.3 0.5 25:03.03 mysqld
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
3154 apache 20 0 640868 400 280 S 0.0 0.0 0:00.01 apache2
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:
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
KiB Mem: 16391768 total, 15328168 used, 1063600 free, 1373716 buffers KiB Swap: 33554428 total, 3100220 used, 30454208 free, 9236360 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
23139 root 20 0 4181236 589852 44424 S 5.3 3.6 4:14.29 vdr
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
17903 root 20 0 92956 25716 3776 S 0.0 0.2 0:00.53 gg_launcher.pl
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
23260 root 20 0 17944 4080 1624 S 0.0 0.0 0:01.43 bash
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):
adler VDR # grep proc/sys/vm /etc/local.d/*
echo 90 >/proc/sys/vm/dirty_ratio #= 90 (% per process, default = 10)
echo 80 >/proc/sys/vm/dirty_background_ratio #= 80 (% system-wide, default = 5)
echo 6000 >/proc/sys/vm/dirty_expire_centisecs #= 6000 (60s, default = 30s)
echo 4000 >/proc/sys/vm/dirty_writeback_centisecs #= 4000 (40s, default = 5s)
adler VDR # cat /proc/sys/vm/swappiness
60
EDIT: sehe gerade, dass meine Sig nicht mehr stimmt. Ändere gleich
Wenn ich:
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?
Das sind die Bilder als BLOB gespeichert 
Deshalb der Hinweis auf die MySQL Workbench. Damit kannst du dir die Bilder anschauen...
Alternativ kannst du dir auch mit
select media_width, media_height, media_url, media_type, length(media_content) from series_media where series_id = xxxdie Größe der gespeicherten Bilder anzeigen lassen.
Ciao Louis
Scheint wirklich ImageMagick zu sein:
(gdb) bt
#0 0x00007f1f2e038855 in raise () from /lib64/libc.so.6
#1 0x00007f1f2e039cc7 in abort () from /lib64/libc.so.6
#2 0x00007f1f2e92ddc5 in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libstdc++.so.6
#3 0x00007f1f2e92bea6 in ?? () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libstdc++.so.6
#4 0x00007f1f2e92bed3 in std::terminate() () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libstdc++.so.6
#5 0x00007f1f2e92c15e in __cxa_throw () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libstdc++.so.6
#6 0x00007f1f1fabffa7 in Magick::throwException(MagickCore::_ExceptionInfo&) () from /usr/lib64/libMagick++-6.Q16.so.3
#7 0x00007f1f1fac9ea0 in Magick::Image::sample(Magick::Geometry const&) () from /usr/lib64/libMagick++-6.Q16.so.3
#8 0x00007f1f1fd95190 in cImageLoader::LoadPoster (this=0x7fff203a0a20, poster=0x7f1e94c8cdf8 "/var/vdr/scraper2vdr-images/movies/18089/poster.jpg", width=-2147483648,
height=-2147483648) at imageloader.c:124
#9 0x00007f1f1fd77083 in cNopacityDisplayChannelView::DrawPoster (this=0xb7d3330, event=0x7f1ee851fe10, initial=false) at displaychannelview.c:607
#10 0x00007f1f1fd54a2d in cNopacityDisplayChannel::SetEvents (this=0xb7bb090, Present=0x7f1ee851fe10, Following=0x7f1ee86292f0) at displaychannel.c:115
#11 0x00000000004f38e5 in cDisplayChannel::DisplayInfo (this=0x14d12c90) at menu.c:4193
#12 0x00000000004f448b in cDisplayChannel::ProcessKey (this=0x14d12c90, Key=kChanUp) at menu.c:4377
#13 0x000000000057a610 in main (argc=45, argv=0x7fff203a1238) at vdr.c:1125Full Backtrace anbei.
Welche ImageMagick-Version empfiehlst Du? Oder lohnt es sich komplett auf GraphicsMagick umzustellen - ich kann nicht beide parallel installieren.
Plugin baut gerade mit diese Änderung:
diff --git a/displaychannelview.c b/displaychannelview.c
index 68a213a..b13c6b5 100644
--- a/displaychannelview.c
+++ b/displaychannelview.c
@@ -589,7 +589,8 @@ void cNopacityDisplayChannelView::DrawPoster(const cEvent *event, bool initial)
mediaWidth = call.banner.width;
mediaHeight = call.banner.height;
mediaPath = call.banner.path;
- } else if (call.type == tMovie && call.poster.path.size() > 0) {
+// } else if (call.type == tMovie && call.poster.path.size() > 0) {
+ } else if (call.type == tMovie && call.poster.path.size() > 0 && call.poster.width > 0 && call.poster.height > 0) {
double ratio = (double)(cOsd::OsdHeight()/3) / (double)call.poster.height;
mediaWidth = ratio * call.poster.width;
mediaHeight = ratio * call.poster.height;
Aber weshalb ich ImageMagick in verdacht habe: das Bild ist ok - beim nächsten mal funktioniert genau das gleiche Umschalten mit Bildanzeige ja...
Gruß, Ingo
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!