Recent Posts

Pages: 1 ... 8 9 [10]
91
VOMP for Raspberry Pi / Re: Overflow with recording >4G?
« Last post by MartenR on November 22, 2014, 09:39:04 »
Hi,
well, I do not use files larger than 4 GB (since some file systems and network have still the 4 GB restriction).
So it is hard for me to debug it.
But anyway, can you please answer the following questions:
1) We are using the framenumber as index, so what does the recording time say (if you hit ok), does it jump backward or does it stay at advanced time?
2) A log of the serverside would be helpful, especially the " "getblock pos = %llu length = %lu" messages will help, where the problem is. (server or client side).
3) Do you use the windows client or mvp client? If yes does it happen there as well?

Marten
 
92
VOMP for Raspberry Pi / Overflow with recording >4G?
« Last post by ulrhom on November 21, 2014, 07:38:14 »
Hi,

first of all: Thanks for the great VOMP: It seems to be the perfect frontend for my VDR.

I've increased in my VDR the size of recording chunks:
MaxVideoFileSize = 20000

Now I've tried to play a recording of approx 8G size with raspi vomp: the playback jumped after approx 4G back to the beginning. So i guess there is somewhere a unint32_t overflow.




93
VOMP for Raspberry Pi / Re: Vompclient with tvscraper support
« Last post by MartenR on October 28, 2014, 07:40:49 »
Is now fixed!

Marten
94
VOMP for Raspberry Pi / Re: Vompclient with tvscraper support
« Last post by JTe on October 27, 2014, 19:31:15 »
Ok. If you cannot reproduce it, let me know.

-JTe
95
VOMP for Raspberry Pi / Re: Vompclient with tvscraper support
« Last post by MartenR on October 27, 2014, 19:27:07 »
Quote
I was meaning the debugging (logging) switch -d. I did only manage to get the log once, after that every run seems to work, but without the -d switch it always gets jammed with a black screen, without loading the start menu.
Then do not do the test, this sounds like I can reproduce it this way.

Marten
96
VOMP for Raspberry Pi / Re: Vompclient with tvscraper support
« Last post by JTe on October 27, 2014, 19:22:46 »
I will make the tests. It will just take some time as I compile in native raspi environment and it takes some time to compile.

 I was meaning the debugging (logging) switch -d. I did only manage to get the log once, after that every run seems to work, but without the -d switch it always gets jammed with a black screen, without loading the start menu.

-JTe
97
VOMP for Raspberry Pi / Re: Vompclient with tvscraper support
« Last post by MartenR on October 27, 2014, 18:19:19 »
Hard to say, I have changed a lot during the last commit.
So we have to revert it, step by step.
1) First try, can you please use mutex.h and mutex.cc of the commit before. If it works, we already have to problem.
2) If this did not fix, it try to use the old boxstack.cc and boxstack.h with the new mutex files.

1 and 2 are unrelated, other changes are connected to optimizations in the rendering classes, so not so easy to disentangle for this:

3) It it would be helpful, if you attach the debugger using "gdb -tui -p PIDOFVOMP", you can get the pid of vomp using ps. Now, using "info threads" should give a list where all threads are. You can select every thread with "thread THREADNUMBER", now it getting information, where every thread is using, "bt" can help. 

Another question, before you only see the keep alive packets, are the log lines then always the same?
Furthermore what do you mean with "with debugging"? Compiling with debug symbols? With attached debugger?  ???  Maybe there is a way, where I can reproduce it... I tested everything with a debug build and with switch "-d".

Marten
98
VOMP for Raspberry Pi / Re: Vompclient with tvscraper support
« Last post by JTe on October 27, 2014, 18:08:12 »
Latest build wont start well. It only displays black screen and produces following log where the two last lines keep repeating forever:

Code: [Select]
19:59:00.003580 [debug]  3746 Timers - Starting set timer 1
19:59:00.004492 [debug]  3746 BoxStack - Update called
19:59:00.005317 [debug]  3746 BoxStack - Locked for update
19:59:00.006289 [debug]  3746 BoxStack - Unlocked for update
19:59:00.007019 [debug]  3746 Timers - timerEventFinished for 0x1b437d8
19:59:00.007831 [debug]  3746 Timers - timerEventFinished RESTART for 0x1b437d8
19:59:00.508847 [debug]  3746 VDR - Sending KA packet
19:59:00.510480 [debug]  3746 VDR - Rxd correct KA reply
19:59:06.512940 [debug]  3746 VDR - Sending KA packet
19:59:06.514575 [debug]  3746 VDR - Rxd correct KA reply
19:59:12.515971 [debug]  3746 VDR - Sending KA packet
19:59:12.517639 [debug]  3746 VDR - Rxd correct KA reply
19:59:18.521079 [debug]  3746 VDR - Sending KA packet
19:59:18.522772 [debug]  3746 VDR - Rxd correct KA reply
19:59:24.525082 [debug]  3746 VDR - Sending KA packet
19:59:24.526744 [debug]  3746 VDR - Rxd correct KA reply

However if I enable debugging I am able to start the client most of the time. So it is probably a timing problem and when the client runs slower (with debugging) it will start every now and then. After the client is jammed I have to kill it with -9 to stop it.
99
I can confirm -it works now!

-JTe
100
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
Pages: 1 ... 8 9 [10]