Should the recordings menu of the TV scraper branch work already? For me it shows "Loading.." and after that the vomp client will crash in less than a second. Normal log shows (not much):
08:46:38.210061 [debug] 21533 VDR - Sending KA packet
08:46:38.238532 [debug] 21533 VDR - Rxd a response packet, requestID=126, len=259692
08:46:38.238873 [debug] 21533 VDR - RR unsleep
08:46:38.238998 [debug] 21533 VDR - Packet delivered to me, requestID: 126
08:46:38.246620 [debug] 21533 VDR - Rxd correct KA reply
08:46:38.301587 [debug] 21533 VDR - RR sleep - opcode 12
08:46:38.302367 [debug] 21533 VDR - Rxd a response packet, requestID=127, len=14
08:46:38.302989 [debug] 21533 VDR - RR unsleep
08:46:38.303132 [debug] 21533 VDR - Packet delivered to me, requestID: 127
08:46:38.303259 [debug] 21533 RecMan - Sort
Sure it should work. But it is in pre-alpha test and I suspect many segfaults.
So your input on this is welcome. You should type in bash before executing vomp:
ulimit -c unlimited
this will turn the generation of core files on.
Then execute vomp and provoke the segfault.
After this execute
gdb -tui vompclient core
for looking at the core file.
It will show you the position were it crashed. This information will be very helpful for me.
Important is to know the position fromwhere the crash inside vomp came. So "bt" the backtrace for the calling stack and "up" and "down" to move up and down the calling sequence will be helpful for me to fix it.
Marten
Ok, it shows the following address:
[New LWP 2311]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
Core was generated by `./vompclient'.
Program terminated with signal 11, Segmentation fault.
#0 0x000c81a4 in TVMediaInfo::setStaticArtwork (this=0x0, id=16)
at tvmedia.cc:74
#1 0x0006361c in VRecordingListAdvanced::drawData (this=0x103f1c0,
doIndexPop=false) at vrecordinglistadvanced.cc:116
#2 0x000639a8 in VRecordingListAdvanced::draw (this=0x103f1c0,
doIndexPop=false) at vrecordinglistadvanced.cc:174
#3 0x0006046c in VRecordingList::load (this=0x103f1c0)
at vrecordinglist.cc:428
#4 0x00072244 in VWelcome::doRecordingsList (this=0x105c540)
at vwelcome.cc:354
#5 0x00071ef0 in VWelcome::handleCommand (this=0x105c540, command=37)
at vwelcome.cc:257
#6 0x00057d24 in BoxStack::handleCommand (this=0x101b2e8, command=37)
at boxstack.cc:521
#7 0x0000ee24 in Command::handleCommand (this=0x101b3b0, button=37)
at command.cc:506
#8 0x0000e800 in Command::run (this=0x101b3b0) at command.cc:249
#9 0x000cbfe0 in main (argc=1, argv=0xbed0a814) at main.cc:402
Thanks, I have located the problem a fix is in git.
The bug was related to a folder without an recording, probably a folder with folder.
I do not have this, so other crashes are possible, since I did not test this.
Marten
I can confirm -it works now!
-JTe