Hat jemand zufällig eine Kopie von der SatIP-Spezifikation? http://www.satip.info ist derzeit (22.05.2024) nicht erreichbar...
Beiträge von heifisch
-
-
Bitte testen.
heifisch , ich hatte bereits mit dem letzten git commit einen Fehler gefixed, aufgrund von dem die Zuordnung von geschnittenen Aufnahmen zum Film verloren ging. Bitte teste doch mal das neueste git ...
Danke MarkusE .
Leider bekomme ich damit ein Segfault:
Code: bt
Alles anzeigen(gdb) bt #0 0x00007f314487822c in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::operator= (__s=Python Exception <class 'gdb.MemoryError'>: Cannot access memory at address 0x8 #1 cTVDBSeries::ParseJson_Series (this=this@entry=0x7f3121fa8060, jSeries=..., displayLanguage=displayLanguage@entry=0x0) at thetvdbscraper/tvdbseries.c:60 #2 0x00007f31448a43ee in cTVDBScraper::StoreSeriesJson (this=0x7f30f4079950, seriesID=seriesID@entry=387540, forceUpdate=forceUpdate@entry=true) at thetvdbscraper/thetvdbscraper.c:173 #3 0x00007f31448d1180 in cTvDbTvScraper::enhance1 (this=this@entry=0x7f30f407ace0, searchResultTvMovie=..., lang=<optimized out>) at /usr/local/src/vdr-plugin-tvscraper/searchResultTvMovie.h:51 #4 0x00007f31448896f5 in cSearchEventOrRec::enhance1 (sR=..., searchEventOrRec=...) at /usr/local/src/vdr-plugin-tvscraper/searchEventOrRec.c:849 #5 0x00007f314487b6b1 in cSearchEventOrRec::selectBestAndEnhanceIfRequired (this=this@entry=0x7f3121fa8bf0, begin=Python Exception <class 'gdb.error'>: value has been optimized out , end=end@entry=..., new_end=..., minDiff=minDiff@entry=0.200000003, func=func@entry=0x7f3144889680 <cSearchEventOrRec::enhance1(searchResultTvMovie&, cSearchEventOrRec&)>) at /usr/local/src/vdr-plugin-tvscraper/searchEventOrRec.c:805 #6 0x00007f314488ff43 in cSearchEventOrRec::ScrapFind (this=this@entry=0x7f3121fa8bf0, searchResults=std::vector of length 83, capacity 128 = {...}, foundName=..., episodeSearchString=...) at /usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/bits/stl_iterator.h:1076 #7 0x00007f31448a9b55 in cSearchEventOrRec::ScrapFindAndStore (this=this@entry=0x7f3121fa8bf0, movieOrTv=...) at /usr/local/src/vdr-plugin-tvscraper/searchEventOrRec.c:348 #8 0x00007f31448aa337 in cSearchEventOrRec::Scrape (this=this@entry=0x7f3121fa8bf0, statistics=@0x7f3121fa89ec: 0) at /usr/local/src/vdr-plugin-tvscraper/searchEventOrRec.c:238 #9 0x00007f31448ae87f in cTVScraperWorker::ScrapEPG (this=this@entry=0x562e87a65a60) at /usr/local/src/vdr-plugin-tvscraper/worker.c:238 #10 0x00007f31448b2c28 in cTVScraperWorker::Action (this=0x562e87a65a60) at /usr/local/src/vdr-plugin-tvscraper/worker.c:589 #11 cTVScraperWorker::Action (this=0x562e87a65a60) at /usr/local/src/vdr-plugin-tvscraper/worker.c:561 #12 0x0000562e8768fd15 in cThread::StartThread (Thread=0x562e87a65a60) at thread.c:293 #13 0x00007f315926a1d3 in ??? () at /lib64/libc.so.6 #14 0x00007f31592eb80c in ??? () at /lib64/libc.so.6 (gdb)
Wann der Segfault auftritt, konnte ich noch nicht nachvollziehen.
Sieht danach aus, das keine Benutzerinteraktion nötig ist.
Am Anhang noch bt full
-
Auch habe ich das Problem, dass manche neuen Aufnahmen, die eigentlich schon einen Bezug zu tvscraper hatten, irgendwann nach einem reboot in live wieder ungescrapt erscheinen.
Wenn ich die Aufnahme dann manuell scrape, kommen meist wieder die Einträge.
Kann das auch mit dem API-Fehler zusammenhängen?
-
Hallo,
ich habe seit einiger Zeit (weiß aber nicht seit wann) Probleme mit dem Scraping von Aufnahmen.
Hier mal ein Beispiel aus der Serie Sherlock:
Code: ls -lisa /video/videos/_Sherlock/04_Sherlock_-_Ein_Skandal_in_Belgravia/2016-07-18.20.15.24-0.rec/
Alles anzeigenvdr ~ # ll /video/videos/_Sherlock/04_Sherlock_-_Ein_Skandal_in_Belgravia/2016-07-18.20.15.24-0.rec/ insgesamt 4221988 19358570948 0 drwxrwxrwx 2 root root 204 3. Apr 13:39 . 21477350616 0 drwxr-xr-x 3 root root 47 28. Mar 07:50 .. 19358594250 2048048 -rw-rw-rw- 1 root root 2097199032 18. Jul 2016 00001.ts 19358594251 2048172 -rw-rw-rw- 1 root root 2097327060 18. Jul 2016 00002.ts 19358594252 123908 -rw-rw-rw- 1 root root 126878568 18. Jul 2016 00003.ts 19358570955 660 -rw-r--r-- 1 root root 675061 30. Aug 2022 fanart.jpg 19358594253 1052 -rw-rw-rw- 1 root root 1074352 18. Jul 2016 index 19358570980 4 -rw-rw-rw- 1 root root 1196 7. Oct 2022 info 19358594255 4 -rw-rw-rw- 1 root root 1676 18. Jul 2016 markad.log 19358619130 4 -rw-r--r-- 1 root root 51 14. Jun 2020 marks 19358570954 132 -rw-r--r-- 1 root root 132155 30. Aug 2022 poster.jpg 19358594256 4 -rw-r--r-- 1 root root 9 14. Jun 2020 resume
Code: cat /video/videos/_Sherlock/04_Sherlock_-_Ein_Skandal_in_Belgravia/2016-07-18.20.15.24-0.rec/info
Alles anzeigenvdr ~ # cat /video/videos/_Sherlock/04_Sherlock_-_Ein_Skandal_in_Belgravia/2016-07-18.20.15.24-0.rec/info C S19.2E-1-1051-28722 Einsfestival E 37700 1468865700 5400 4E F T Sherlock - Ein Skandal in Belgravia S Spielfilm Großbritannien 2011 (Sherlock - A Scandal in Belgravia) D Sherlock und Watson werden von der Regierung mit einem äußerst delikaten Fall betraut: Die Domina Irene Adler hat heimlich kompromittierende Fotos von einem Mitglied der britischen Königsfamilie gemacht. Nun sollen die beiden Privatermittler das belastende Bildmaterial sicherstellen. Was auf den ersten Blick wie keine große Herausforderung erscheint, entwickelt sich sehr schnell zu einem der schwierigsten Fälle, mit dem Sherlock je konfrontiert wurde. Denn nicht nur kommt er durch Irene einem mörderischen Komplott auf die Spur - der unnahbare Ermittler beginnt auch, sich in die schöne und gefährliche Frau zu verlieben.|Produziert in HD G 10 X 1 03 deu 16:9 X 2 03 deu stereo X 4 44 deu Dolby Digital 5.1 X 3 01 deu X 2 48 deu mit Audiodeskription X 2 03 mis V 1468865700 F 25 P 50 L 99 X 2 05 mis Dolby Digital 5.1 @ <epgsearch><channel>24 - Einsfestival</channel><update>0</update><eventid>37700</eventid><bstart>0</bstart><bstop>0</bstop><start>1468865700</start><stop>1468871100</stop></epgsearch> O 0
Code: log
Alles anzeigenApr 3 13:45:21 vdr vdr[3082]: [3287] SVDRP vdr < 127.0.0.1:41864 client connection accepted Apr 3 13:45:21 vdr vdr[3082]: [3287] SVDRP vdr > 127.0.0.1:41864 server created Apr 3 13:45:21 vdr vdr[3082]: [3148] tvscraper: scanning video dir Apr 3 13:45:21 vdr vdr[3082]: [3287] SVDRP vdr < 127.0.0.1:41864 connection closed Apr 3 13:45:21 vdr vdr[3082]: [3287] SVDRP vdr < 127.0.0.1:41864 server destroyed Apr 3 13:45:21 vdr vdr[3082]: [3148] tvscraper: Scrap recording "/video/videos/_Sherlock/04_Sherlock_-_Ein_Skandal_in_Belgravia/2016-07-18.20.15.24-0.rec" Apr 3 13:45:21 vdr vdr[3082]: [3148] tvscraper: touch "/var/cache/vdr/plugins/tvscraper/.recordingsUpdate" Apr 3 13:45:21 vdr vdr[3082]: [3148] tvscraper: scanning video dir done Apr 3 13:45:21 vdr vdr[3082]: [3148] tvscraper: start scraping epg Apr 3 13:45:21 vdr vdr[3082]: [3148] tvscraper: Schedule was not changed, skipping scan Apr 3 13:45:21 vdr vdr[3082]: [3148] tvscraper: epg scraping done
Das Seltsame ist, dass manche im Verzeichnis Nummerierte Folgen sauber gescrapt werden:Code: log 2Apr 3 14:07:44 vdr vdr[3082]: [3287] SVDRP vdr < 127.0.0.1:54804 client connection accepted Apr 3 14:07:44 vdr vdr[3082]: [3287] SVDRP vdr > 127.0.0.1:54804 server created Apr 3 14:07:44 vdr vdr[3082]: [3148] tvscraper: scanning video dir Apr 3 14:07:44 vdr vdr[3082]: [3287] SVDRP vdr < 127.0.0.1:54804 connection closed Apr 3 14:07:44 vdr vdr[3082]: [3287] SVDRP vdr < 127.0.0.1:54804 server destroyed Apr 3 14:07:44 vdr vdr[3082]: [3148] tvscraper: Scrap recording "/video/videos/_Sherlock/06_Sherlock_-_Der_Reichenbachfall/2016-08-01.20.15.24-0.rec" Apr 3 14:07:44 vdr vdr[3082]: [3148] tvscraper: touch "/var/cache/vdr/plugins/tvscraper/.recordingsUpdate" Apr 3 14:07:44 vdr vdr[3082]: [3148] tvscraper: scanning video dir done Apr 3 14:07:44 vdr vdr[3082]: [3148] tvscraper: start scraping epg
Manchmal werden dann, nach mehrfachen Versuchen, des Scrapens einzelner Aufnahmen, die Daten doch angezeigt.
Irgendwie funktioniert das gerade bei mir recht unzuverlässig.
Aber das hatte doch schon mal alles gut funktioniert.Browser Cache löschen und reload habe ich natürlich gemacht.
MarkusE hast Du eine Idee, was bei mir schief läuft?
-
Ist jetzt nicht so richtig perfekt, andererseits haben wir ja auch nicht mehr soo viele PES Aufnahmen, und ich sehe jetzt nicht, wie ich das in live weiter verbessern kann.
Und man kann die alten Aufnahmen ja auch mit vdr-transcode umwandeln...
-
Wie sieht die URL eigentlich bei sehr alten Aufnahmen aus, die noch im PS Format sind? Also Dateien wie 001.vdr?
Oder wird das von Streamdev nicht unterstützt?
MarkusE Hier eine alte Aufnahme...
Code: ll
Alles anzeigenvdr /video # ll ./videos/%Dreamcatcher/2009-12-11.22.36.50.99.rec/ insgesamt 3563172 15043015358 0 drwxrwxrwx 2 root root 233 26. Dec 15:16 . 12886717807 0 drwxrwxrwx 3 root root 48 7. Jan 2019 .. 15043069757 2048180 -rw-rw-rw- 1 root root 2097334206 7. Jan 2019 001.vdr 15043069758 1513256 -rw-rw-rw- 1 root root 1549571211 7. Jan 2019 002.vdr 15043015338 152 -rw-r--r-- 1 root root 151723 30. Aug 2022 fanart.jpg 15043069759 1432 -rw-rw-rw- 1 root root 1464816 7. Jan 2019 index.vdr 15043069760 4 -rw-rw-rw- 1 root root 717 7. Jan 2019 info.vdr 15043069761 4 -rw-rw-rw- 1 root root 77 7. Jan 2019 marks.vdr 15043015331 132 -rw-r--r-- 1 root root 132812 30. Aug 2022 poster.jpg 15043069762 4 -rw-rw-rw- 1 root root 4 26. Dec 2022 resume.vdr 15043069324 4 -rw-r--r-- 1 root root 116 26. Mar 17:22 tvscraper.json 15043015330 4 -rw-r--r-- 1 root root 230 8. Oct 20:52 tvscrapper.json.bak
-
Am besten bei 545 und cuda-12.3 bleiben. Mein libplacebo ist libplacebo-349, das funkt noch.
Ja, ich gehe gerade wieder zurück...
-
Hallo jojo61,
ich habe mal nvidia-drivers 550.67 mit softhdcuvid ausprobiert, bekomme allerdings einen Segfault.
kernel: 6.8.2
ffmpeg: 6.1.1
nvidia-cuda-toolkit: 12.3.2
Hier der bt:
Code: bt
Alles anzeigen[Switching to Thread 0x7feb6edfd6c0 (LWP 18015)] 0x00007febf04a712c in createTextureDst (decoder=decoder@entry=0x557d54023710, anz=<optimized out>, size_x=size_x@entry=720, size_y=size_y@entry=576, PixFmt=PixFmt@entry=AV_PIX_FMT_NV12) at video.c:2332 2332 fd = dup(decoder->pl_frames[i].planes[n].texture->shared_mem.handle.fd); (gdb) bt #0 0x00007febf04a712c in createTextureDst (decoder=decoder@entry=0x557d54023710, anz=<optimized out>, size_x=size_x@entry=720, size_y=size_y@entry=576, PixFmt=PixFmt@entry=AV_PIX_FMT_NV12) at video.c:2332 #1 0x00007febf04a77c7 in CuvidCreateSurfaces (PixFmt=AV_PIX_FMT_NV12, height=<optimized out>, width=<optimized out>, decoder=0x557d54023710) at video.c:1598 #2 CuvidSetupOutput (decoder=0x557d54023710) at video.c:2667 #3 Cuvid_get_format (decoder=0x557d54023710, video_ctx=0x7feb24000b70, fmt=<optimized out>) at video.c:2984 #4 0x00007febee2c37b8 in ??? () at /usr/lib64/libavcodec.so.60 #5 0x00007febee2a519a in ??? () at /usr/lib64/libavcodec.so.60 #6 0x00007febeb2201e0 in ??? () at /usr/lib64/libnvcuvid.so.1 #7 0x00007febeb280ef8 in ??? () at /usr/lib64/libnvcuvid.so.1 #8 0x00007febeb25f017 in ??? () at /usr/lib64/libnvcuvid.so.1 #9 0x00007febeb25f292 in ??? () at /usr/lib64/libnvcuvid.so.1 #10 0x00007febeb281323 in ??? () at /usr/lib64/libnvcuvid.so.1 #11 0x00007febeb28197e in ??? () at /usr/lib64/libnvcuvid.so.1 #12 0x00007febeb21ff7b in ??? () at /usr/lib64/libnvcuvid.so.1 #13 0x00007febee2a3e35 in ??? () at /usr/lib64/libavcodec.so.60 #14 0x00007febee2a478c in ??? () at /usr/lib64/libavcodec.so.60 #15 0x00007febee2c2072 in ??? () at /usr/lib64/libavcodec.so.60 #16 0x00007febee2c28ec in avcodec_send_packet () at /usr/lib64/libavcodec.so.60 #17 0x00007febf04b0300 in CodecVideoDecode (decoder=0x557d53cddbe0, avpkt=0x7feb6edfcd50) at codec.c:525 #18 0x00007febf04a0fd0 in VideoDecodeInput (stream=0x7febf04d0f00 <MyVideoStream>, trick=<optimized out>) at softhddev.c:1921 #19 0x00007febf04a4415 in CuvidDisplayHandlerThread () at video.c:5000 #20 0x00007febf04a4397 in VideoDisplayHandlerThread (dummy=<optimized out>) at video.c:5777 #21 0x00007febf0c041d3 in ??? () at /lib64/libc.so.6 #22 0x00007febf0c8580c in ??? () at /lib64/libc.so.6
Code: bt full
Alles anzeigen(gdb) bt full #0 0x00007febf04a712c in createTextureDst (decoder=decoder@entry=0x557d54023710, anz=<optimized out>, size_x=size_x@entry=720, size_y=size_y@entry=576, PixFmt=PixFmt@entry=AV_PIX_FMT_NV12) at video.c:2332 ok = true ext_desc = {type = 1860157936, handle = {fd = -840531456, win32 = {handle = 0x735526dbcde68200, name = 0x7feb24bc3600}}, size = 0, flags = 576, reserved = {0, 603982704, 32747, 23, 0, 720, 0, 1409431312, 21885, 4031393659, 32747, 16, 48, 1860156720, 32747, 1860156528}} tex_desc = {offset = 0, arrayDesc = {Width = 720, Height = 140651325567264, Depth = 720, Format = 576, NumChannels = 0, Flags = 7}, numLevels = 1860156720, reserved = {32747, 3960484482, 32747, 616726208, 0, 12, 0, 603979824, 32747, 4294967192, 4294967295, 1860156952, 32747, 2, 0, 0}} n = <optimized out> i = 0 size = 2 fd = <optimized out> fmt = 0x7feb580246d0 tex = <optimized out> img = <optimized out> pl = 0x557d54023a98 #1 0x00007febf04a77c7 in CuvidCreateSurfaces (PixFmt=AV_PIX_FMT_NV12, height=<optimized out>, width=<optimized out>, decoder=0x557d54023710) at video.c:1598 i = <optimized out> i = <optimized out> __FUNCTION__ = "CuvidCreateSurfaces" #2 CuvidSetupOutput (decoder=0x557d54023710) at video.c:2667 #3 Cuvid_get_format (decoder=0x557d54023710, video_ctx=0x7feb24000b70, fmt=<optimized out>) at video.c:2984 fmt_idx = <optimized out> bitformat16 = <optimized out> deint = 0 ist = <optimized out> __FUNCTION__ = "Cuvid_get_format" #4 0x00007febee2c37b8 in ??? () at /usr/lib64/libavcodec.so.60 #5 0x00007febee2a519a in ??? () at /usr/lib64/libavcodec.so.60 #6 0x00007febeb2201e0 in ??? () at /usr/lib64/libnvcuvid.so.1 #7 0x00007febeb280ef8 in ??? () at /usr/lib64/libnvcuvid.so.1 #8 0x00007febeb25f017 in ??? () at /usr/lib64/libnvcuvid.so.1 #9 0x00007febeb25f292 in ??? () at /usr/lib64/libnvcuvid.so.1 #10 0x00007febeb281323 in ??? () at /usr/lib64/libnvcuvid.so.1 #11 0x00007febeb28197e in ??? () at /usr/lib64/libnvcuvid.so.1 #12 0x00007febeb21ff7b in ??? () at /usr/lib64/libnvcuvid.so.1 #13 0x00007febee2a3e35 in ??? () at /usr/lib64/libavcodec.so.60 #14 0x00007febee2a478c in ??? () at /usr/lib64/libavcodec.so.60 #15 0x00007febee2c2072 in ??? () at /usr/lib64/libavcodec.so.60 #16 0x00007febee2c28ec in avcodec_send_packet () at /usr/lib64/libavcodec.so.60 #17 0x00007febf04b0300 in CodecVideoDecode (decoder=0x557d53cddbe0, avpkt=0x7feb6edfcd50) at codec.c:525 video_ctx = 0x7feb24000b70 frame = 0x0 ret = <optimized out> ret1 = <optimized out> got_frame = 0 consumed = 0 first_time = <optimized out> pkt = 0x7feb6edfcd50 #18 0x00007febf04a0fd0 in VideoDecodeInput (stream=0x7febf04d0f00 <MyVideoStream>, trick=<optimized out>) at softhddev.c:1921 filled = <optimized out> avpkt = 0x7febf04d1420 <MyVideoStream+1312> saved_size = 1048576 #19 0x00007febf04a4415 in CuvidDisplayHandlerThread () at video.c:5000 i = 0 err = <optimized out> allfull = 0 decoded = <optimized out> filled = <optimized out> nowtime = {tv_sec = 301, tv_nsec = 670824549} decoder = 0x557d54023710 #20 0x00007febf04a4397 in VideoDisplayHandlerThread (dummy=<optimized out>) at video.c:5777 __cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {140649154206940, 6294807760410578545, -160, 0, 140736397976800, 140649145815040, -6301244028268245391, -6301583876245746063}, __mask_was_saved = 0}}, __pad = {0x7feb6edfcef0, 0x0, 0x0, 0x0}} __cancel_routine = 0x7febf04a2f90 <delete_decode> __cancel_arg = <optimized out> __not_first_call = <optimized out> #21 0x00007febf0c041d3 in ??? () at /lib64/libc.so.6 #22 0x00007febf0c8580c in ??? () at /lib64/libc.so.6
Der Test ist wahrscheinlich noch zu früh, aber vielleicht kannst Du ja das Problem erkennen und einen Patch machen.
Ich würde auch wieder Testen.
Danke und Gruß
-
Im git ist ein update.
Damit sind die scraper Daten für geschnittene Aufnahmen über das VDR interne Service Interface wieder sofort verfügbar.
Sollte mit live und den Skins funktionieren.
Bitte testen.
Hier mit Live getestet, funktioniert es wie es soll.Vielen Dank!
-
Was meint ihr?
~ Markus
Hallo MarkusE
So wie es jetzt ist, finde ich es nicht so gut, da man nach jedem Schneiden die Aufnahme neu scrappen muss.
Oder, Du könntest dies nach dem Schneiden automatisieren.
Gruß und Danke
-
Mit welchem Plugin "siehst" Du die Bilder? Live? Oder ein skin? Welcher?
Hier auch dieses Verhalten in Live.
Nach dem Schneiden erscheint die geschnittene Aufnahme ungescrapt und muss manuell neu gescrapt werden.
-
Hallo Markus,
Letzte Woche gab es den RPI5 bei Pollin zu vernünftigen Preisen, und da habe ich zugeschlagen:
Zu welchen Preisen gab es den denn letzte Woche?
(Damit ich weiß auf was ich warten muss
)
Gruß
Heiko
-
Verwendet jemand zufällig das SAT>IP-Plugin in Verbindung mit ShowChannelNamesWithSource == 2 (Das ist mit Anzeige der SAT-Position.)?
Nur um sicher zu stellen, dass es nicht daran liegt.
Zum Testen sollte es reichen das zu aktivieren und die ein- zwei-mal die Kanalliste durch zu scrollen.
Mit einer DVB-Karte werde ich es die Tage mal testen, aber mit SAT>IP kann ich es leider nicht.
Ich habe das eben mal eingestellt, habe aber nur 56 Kanäle in der channels.conf.
Ich konnte jedoch keinen crash provozieren.
-
Schon mal mit lsof gekuckt?
-
Ich habe so einen EasyTest von Kurth.
Allerdings hat man da auch übersprechen auf andere Adern und mit dem Kabelmantel funktioniert es auch nicht so gut.
Man müsste dann anhand der Lautstärke des Prüfsignals versuchen zu erkennen, wo die Unterbrechung ist.
Kann funktionieren, muss aber nicht.
Wenn eine Neuverkabelung nicht in Frage kommt, würde ich die Leitung an geeigneten Stellen schneiden und mit der Kurzschlussmessmethode heraus zubekommen, wo die Unterbrechung ist. Dann den beschädigten Teil erneuern.
-
Ich habe mal wieder ein seltsames Problem:
Software: Live, aktueller Git Stand und VDR 2.6.6
VDR dumped beim umbenennen von Aufnahmen mit Live. Nur der Name wird geändert, Rest wird nicht angefasst.
Nicht jedes Mal, so nach je 3 bis 4 Umbenennungen der gleichen Aufnahme bekomme ich einen coredump. Ist nicht von der Aufnahme abhängig, habe es mit mehren getestet. Und es crashed auch nicht jedes mal an der gleichen Stelle im VDR Code. Ich hänge mal 2 cordumps an. Für mich sieht das so aus, als ob da irgendeine Variable von Live nicht sauber an VDR übergeben wird. Hat das vielleicht was mit den erweiterten Möglichkeiten beim Umbennen zu tun ? Ich werde daraus nicht schlau.
Hatte ich letztens auch beim Verschieben einer Aufnahme, konnte ich aber noch nicht reproduzieren.
Deshalb noch keine Meldung und kein bt von mir.
-
Im git von live ist ein Update. Bitte testen.
Läuft.
Beim Verschieben kommt eine Fehlermeldung.
Beim Löschen wird der Eintrag aus der Liste entfernt.
Danke!
-
sind im syslog Meldungen wie:
live: rename failed from ...
Nein, solche Meldungen findet grep nicht.
Welche live version?
-
heifisch ,
Hast Du getestet, ob diese Fehler auch in 2.6.5 auftritt? Falls der Fehler in 2.6.5 nicht auftritt: Welcher 2.6.6 Patch verursacht den Fehler?
Tritt der Fehler auch auf, wenn Du die Aufnahme mit
(also ohne live) verschiebst?
Zu Frage 1, muss ich erst wieder downgraden.
Zu Frage 2:
Ohne Live gibt es kein Segfault aber:
Code
Alles anzeigen250-3275 17.04.17 06:37 0:10 %Big Buck Bunny 250 3276 17.04.17 06:37 0:10 %Big Buck Bunny test vdr ~ # svdrpsend LSTR 3276 220 vdr SVDRP VideoDiskRecorder 2.6.6; Mon Jan 29 14:41:24 2024; UTF-8 215-C S13.0E-318-12300-17202 SRF zwei HD 215-E 829 1492403700 600 50 B 215-T Big Buck Bunny 215-S Blender Film Platzhalter 215-D Der mit der freien Grafik-Software Blender produzierte Kurzfilm «Big Buck Bunny» besticht durch detailliert ausgearbeitete animierte Oberflächen und eine witzige Story voller Situationskomik. Das füllige Kaninchen, das dem Film seinen Namen gibt, ist guten Mutes und eigentlich sanftmütig von Natur aus. Doch als ein Flughörnchen gemeinsam mit einem Eichhörnchen und einem Chinchilla auftauchen und seinen Frieden und die schöne Natur stören, beschliesst es, sich an den boshaften Nagetieren zu rächen.|Regie: Sacha Goedegebure|Produzent: Ton Roosendaal|Art Director: Andy Goralczyk|Niederlande 2008||Test|test 215-G 10 215-X 5 0B eng 16:9 215-X 4 44 deu Dolby 5.1 215-X 2 03 deu Stereo 215-X 2 03 deu Stereo 215-V 1492403400 215-F 50 215-P 50 215-L 99 215-O 0 215-@ <epgsearch><channel>24 - SRF zwei HD</channel><update>0</update><eventid>724</eventid><bstart>600</bstart><bstop>600</bstop></epgsearch> 215 End of recording information 221 vdr closing connection vdr ~ # svdrpsend MOVR 3276 TEST 220 vdr SVDRP VideoDiskRecorder 2.6.6; Mon Jan 29 14:42:58 2024; UTF-8 554 Error while moving recording "%Big Buck Bunny test" to "TEST"! 221 vdr closing connection
Ein funktionierender MOVR sieht so aus:
-
Hallo.
Ich habe auch einen Fehler mit tComponent::ToString() gefunden, der in einer seltenen Konstellation mit live zu einem Segfault führt:
Code
Alles anzeigenThread 63 "vdr" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f61e27fc6c0 (LWP 3812)] 0x0000557bc3e2d600 in tComponent::ToString (this=0x0) at epg.c:27 27 epg.c: Datei oder Verzeichnis nicht gefunden. (gdb) bt full #0 0x0000557bc3e2d600 in tComponent::ToString() (this=0x0) at epg.c:27 buffer = "\020h2\334a\177\000\000\000\355vK\350\177\255B\303\337\354\303{U\000\000mh2\334a\177\000\000\020h2\334a\177\000\000\260?\v\320a\177\000\000\303\337\354\303{U\000\000ph2\334a\177\000\000\001\000\000\000\000\000\000\000\377\020\253\020b\177\000\000 \000\000\0000\000\000\000`\200\177\342a\177\000\000\240\177\177\342a\177\000\000\000\355vK\350\177\255B=\003\000\000\000\000\000\000\364E\364X\000\000\000\000\020\201\177\342a\177\000\000\020", '\000' <repeats 15 times>, "\303\337\354\303{U\000\0000\000\000\0000\000\000\000\270\200\177\342a\177\000\000\360\177\177\342a\177\000\000\000\355vK\350\177\255B \201\177\342a\177\000\000"... #1 0x0000557bc3e31514 in cEvent::Dump(_IO_FILE*, char const*, bool) const (this=0x7f61dc326810, f=0x7f61d00b3fb0, Prefix=0x557bc3ecdfc3 "", InfoOnly=<optimized out>) at epg.c:475 p = <optimized out> i = 0 #2 0x0000557bc3e75b79 in cRecordingInfo::Write(_IO_FILE*, char const*) const (this=this@entry=0x7f61dc2f2750, f=0x7f61d00b3fb0, Prefix=Prefix@entry=0x557bc3ecdfc3 "") at recording.c:582 #3 0x0000557bc3e75f3b in cRecordingInfo::Write() const (this=this@entry=0x7f61dc2f2750) at /var/tmp/portage/media-video/vdr-2.6.6/work/vdr-2.6.6/tools.h:499 f = {f = 0x7f61d00b3fb0, fileName = 0x7f61dc15afc0 "&\354\024*f\177", tempName = 0x7f61dc08c380 "&\354\024*f\177.$$$"} Result = false #4 0x00007f62102b1cea in vdrlive::RecordingsManager::UpdateRecording(cRecording const*, cSv, cSv, bool, cSv, cSv, cSv) const (this=<optimized out>, recording=<optimized out>, directory=..., name=..., copy=false, title=..., shorttext=..., description=...) at recman.cpp:146 oldname = "/video/%Big_Buck_Bunny_nodelete/2017-04-17.06.37.24-0.rec" found = <optimized out> filename = "videos/___0_uncut/%Big_Buck_Bunny_nodelete" newname = "/video/videos/___0_uncut/%Big_Buck_Bunny_nodelete/2017-04-17.06.37.24-0.rec" Recordings_Lock = {stateKey = {stateLock = 0x557bc3f94020 <cRecordings::recordings+32>, write = true, state = -1, timedOut = false}, list = 0x557bc3f94000 <cRecordings::recordings>} Recordings = <optimized out> desc = "Der mit der freien Grafik-Software Blender produzierte Kurzfilm «Big Buck Bunny» besticht durch detailliert ausgearbeitete animierte Oberflächen und eine witzige Story voller Situationskomik. Das f"... info = 0x7f61dc2f2750 #5 0x00007f6210422d7b in (anonymous namespace)::_component_::operator()(tnt::HttpRequest&, tnt::HttpReply&, tnt::QueryParams&) (this=<optimized out>, request=<optimized out>, reply=..., qparam=<optimized out>) at /usr/local/src/vdr-plugin-live/pages/edit_recording.ecpp:68 copy_only = false spoint = {_active = true, _reply = @0x7f61e27f8c20, _pos = 0} ajaxReq = false message = "" returnToReferer = false _cxxtools_tracer = {_impl = 0x7f61d0002fe0} _tntChunks = {_dataObject = 0x7f621046fc00 <incomplete sequence \304>} recid = "recording_02FF9CD4E619B4FAD9409B3666FE5CCA" async = "" history_num_back = <optimized out> name = "%Big Buck Bunny nodelete" directory = "videos/ 0 uncut" newdir = "." title = "Big Buck Bunny" shorttext = "Blender Film Platzhalter" description = "Der mit der freien Grafik-Software Blender produzierte Kurzfilm «Big Buck Bunny» besticht durch detailliert ausgearbeitete animierte Oberflächen und eine witzige Story voller Situationskomik. Das f"... delresume = "" delmarks = "" copy = "" sort = "" filter = "" flat = "" logged_in_pointer = <optimized out> logged_in = <optimized out> active_r_pointer = <optimized out> active_r = <optimized out> recording_pointer = 0x7f61d0050680 recording = @0x7f61d0050680: 0x7f61dc093140 pageTitle_pointer = 0x7f61d00500a0 pageTitle = "" #6 0x00007f62101c7ecc in tnt::Worker::dispatch(tnt::HttpRequest&, tnt::HttpReply&) () at /usr/lib64/libtntnet.so.13 #7 0x00007f62101cd579 in tnt::Worker::processRequest(tnt::HttpRequest&, std::basic_iostream<char, std::char_traits<char> >&, unsigned int) () at /usr/lib64/libtntnet.so.13 #8 0x00007f62101cdddd in tnt::Worker::run() () at /usr/lib64/libtntnet.so.13 #9 0x00007f62101ce58a in cxxtools::DetachedThread::exec() () at /usr/lib64/libtntnet.so.13 #10 0x00007f620ff45ee4 in () at /usr/lib64/libcxxtools.so.10 #11 0x00007f6210a22f0b in () at /lib64/libc.so.6 #12 0x00007f6210aa3288 in () at /lib64/libc.so.6
Der Fehler tritt auf, wenn ich in live versuche eine Aufnahme zu verschieben, diese aber vorher auf der Konsole manuell schon gelöscht, jedoch kein touch .update ausgeführt habe.
MarkusE ich weiß jetzt nicht ob der Fehler in VDR oder in live ist, aber da Du den Patch vorgeschlagen hast und auch live entwickelst, kannst du evtl. sehen woran es liegt.
Gruß und Danke
Heiko