News:

Latest versions:
Server plugin: 0.5.1
MVP dongle: 0.5.2
Raspberry Pi client: 0.5.2
Windows client: 0.5.2-1

Main Menu

Seldom crashes with current dongle and suggestion for deault tcp size

Started by muellerph, September 12, 2008, 14:32:17

Previous topic - Next topic

muellerph

Hello,

a) crashes:
I have seldom (~ once a week) crashes with current dongle.
It only happens when playing recordings and pressing intensively 10s and/or 60s foreward or backwards.
I know a log is mandatory, but as it is so seldom, I don't have enabled it yet. Will do when I come to it.

b) Tcp package size:
Currently default tcp package size is 2048. I had for some channels with high bitrates a lot of times stuttering in the tone. Regardless if it was live-tv or if it was playing from recording from a high bitrate channel.
Now that I changed the tcp package size to 4096, these hickups are gone (at least much much more seldom).
As I now assume, the hickups came from network concurrency, would it make sense to increase this default package size to at least 4096?

Chris

Crashing: I also see this frequency of crash, but in my case most of the time it locks up the MVP entirely which means it's a crash in the kernel drivers or hardware. I see this as a fault in a layer that is out of our control.. Now maybe there is something vomp is doing which the hardware doesn't like, or maybe there would be a change to vomp possible that would prevent it, but with the MVP locking up entirely it's very difficult to debug.

TCP window size: What type of MVP was this with?

muellerph

Quote from: Chris on September 14, 2008, 16:08:52
Crashing: I also see this frequency of crash, but in my case most of the time it locks up the MVP entirely which means it's a crash in the kernel drivers or hardware. I see this as a fault in a layer that is out of our control.. Now maybe there is something vomp is doing which the hardware doesn't like, or maybe there would be a change to vomp possible that would prevent it, but with the MVP locking up entirely it's very difficult to debug.
Ja, sorry, hangup/freeze is precise.
One pattern I've seen so far, was that shortly before it freezes, the MVP gets a bit unresponsive to the remote key presses. So the last 2 key presses were delay by 0.5 or 1s, but most time (due to the unpatiency) I anyway pressed too many times, so it freezes shortly afterwards.
Looks hard to debug, if you say the box is hanging...

Quote
TCP window size: What type of MVP was this with?
The one in the living room is a E1 - this one is where it is for sure most used one and therefore I've seen it quite often.
But I roughly remember similar with a D3A which is more seldomly used (sleeping room).