PDA

View Full Version : 9/11 dongle test results?



ggee
2007-10-15, 01:25 AM
So is anyone else having issues with this version? I am seeing 2 problems.

1. Remote stops responding. Sometimes after letting the MVP sit for a while and sometimes stops responding while video is playing.

2. Audio sync problems. I don't remember seeing this problem before, but I am seeing audio sync problems the further into the video I get.

I see this on both my wired and wireless MVP.

Thanks,
Greg

mvallevand
2007-10-15, 01:37 AM
I agree on the a/v problems and here is my quote on the original thread:

"I am not recommending this dongle in fact I am going to be coding around this new change, given that I haven't received any positive comments."

I do have a newer dongle that uses current mvpmc demux code that reduces problems. This does seem to be the direction of mvpmc and with a new version 0.3.4 approaching I am trying to work with the change. I probably should upload it.

As for the remote stop responding, I responded to your earlier on this thread:

http://forums.gbpvr.com/showpost.php?p=229207&postcount=1

As I found it takes GBPVR 15 seconds or more to respond to a heartbeat which causes the remote to appear to stop responding because the remote response get queued behind the heartbeat. Your logging might show this.

Martin

ggee
2007-10-16, 02:10 AM
Trying new Oct14 dongle. Yes, as others have said, menus are very fast now. This is great. I'm running the debug version now and capturing all output to logs. Hopefully(actually, hopefully not), we will see something about the timeout.

Greg

mvallevand
2007-10-16, 03:21 AM
Trying new Oct14 dongle. Yes, as others have said, menus are very fast now. This is great. I'm running the debug version now and capturing all output to logs. Hopefully(actually, hopefully not), we will see something about the timeout.

Thanks for the feedback. You may have read I'm running a long test with ML2 and from my debug logs, I have had the heartbeat return in under a second roughly 32,000 times but I've had these 30 slow responses which block gbpvr and that is where I'd expect have corresponding problems if a remote key was hit. The 25-30 second pauses are the most disconcerting.



11:32:12 Timer 0 Ping - 10 5000
11:32:41 Handle Ping
14:13:05 Timer 0 Ping - 10 5000
14:13:32 Handle Ping
14:21:38 Timer 0 Ping - 10 5000
14:21:48 Handle Ping
15:02:30 Timer 0 Ping - 10 5000
15:02:35 Handle Ping
16:23:53 Timer 0 Ping - 10 5000
16:24:19 Handle Ping
16:30:12 Timer 0 Ping - 10 5000
16:30:18 Handle Ping
17:10:46 Timer 0 Ping - 10 5000
17:10:55 Handle Ping
17:44:06 Timer 0 Ping - 10 5000
17:44:10 Handle Ping
18:03:03 Timer 0 Ping - 10 5000
18:03:08 Handle Ping
18:28:18 Timer 0 Ping - 10 5000
18:28:28 Handle Ping
20:41:01 Timer 0 Ping - 10 5000
20:41:29 Handle Ping
20:45:16 Timer 0 Ping - 10 5000
20:45:22 Handle Ping
21:19:21 Timer 0 Ping - 10 5000
21:19:29 Handle Ping
21:41:16 Timer 0 Ping - 10 5000
21:41:38 Handle Ping
22:00:07 Timer 0 Ping - 10 5000
22:00:37 Handle Ping
23:14:09 Timer 0 Ping - 10 5000
23:14:15 Handle Ping
23:59:41 Timer 0 Ping - 10 5000
00:00:07 Handle Ping
12:29:16 Timer 0 Ping - 10 5000
12:29:25 Handle Ping
12:51:27 Timer 0 Ping - 10 5000
12:51:35 Handle Ping
13:19:00 Timer 0 Ping - 10 5000
13:19:30 Handle Ping
16:24:21 Timer 0 Ping - 10 5000
16:24:45 Handle Ping
17:37:40 Timer 0 Ping - 10 5000
17:38:01 Handle Ping
17:50:07 Timer 0 Ping - 10 5000
17:50:09 Handle Ping
18:00:07 Timer 0 Ping - 10 5000
18:00:10 Handle Ping
19:15:27 Timer 0 Ping - 10 5000
19:15:35 Handle Ping
19:40:50 Timer 0 Ping - 10 5000
19:40:54 Handle Ping
19:58:30 Timer 0 Ping - 10 5000
19:58:39 Handle Ping
22:07:38 Timer 0 Ping - 10 5000
22:07:41 Handle Ping
22:08:48 Timer 0 Ping - 10 5000
22:09:15 Handle Ping
22:23:03 Timer 0 Ping - 10 5000
22:23:31 Handle Ping


Martin

ggee
2007-10-17, 02:46 AM
Well, it happened again, but I am really upset that there were no logs, AT ALL. I looked at the MVP-PVRX2.exe.log and there is a big gap in the logs. So I can't tell if something went wrong on the pvrx2.exe. The 18:35 was when I rebooted the MVP.



2007-10-15 23:06:12.828 VERBOSE [3] About construct MVP Service Locator request
2007-10-15 23:06:12.828 VERBOSE [3] Sending MVP Service Locator response to 500AA8C0:16882 (control: 5908, streaming: 8339)
2007-10-15 23:06:57.500 VERBOSE [3] Received MVP Service Locator request
2007-10-15 23:06:57.515 VERBOSE [3] Parsing MVP Service Locator request
2007-10-15 23:06:57.593 VERBOSE [3] local address: 00:14:BF:5E:E2:E1 .... 192.168.10.20
2007-10-15 23:06:57.593 VERBOSE [3] local address: 00:14:BF:5E:E2:E1 .... 192.168.10.20
2007-10-15 23:06:57.609 VERBOSE [3] local address: 00:14:BF:5E:E2:E1 .... 192.168.10.20
2007-10-15 23:06:57.609 VERBOSE [3] About construct MVP Service Locator request
2007-10-15 23:06:57.609 VERBOSE [3] Sending MVP Service Locator response to 500AA8C0:16882 (control: 5908, streaming: 8339)
2007-10-16 18:35:09.343 VERBOSE [5] Received BOOTP request from client. bytesReceived: 300 address: 0.0.0.0
2007-10-16 18:36:13.906 VERBOSE [3] Received MVP Service Locator request
2007-10-16 18:36:13.921 VERBOSE [3] Parsing MVP Service Locator request
2007-10-16 18:36:15.093 VERBOSE [3] local address: 00:14:BF:5E:E2:E1 .... 192.168.10.20
2007-10-16 18:36:15.093 VERBOSE [3] local address: 00:14:BF:5E:E2:E1 .... 192.168.10.20
2007-10-16 18:36:15.109 VERBOSE [3] local address: 00:14:BF:5E:E2:E1 .... 192.168.10.20
2007-10-16 18:36:15.109 VERBOSE [3] About construct MVP Service Locator request
I am attaching the logs from the mvpmc. It froze at 10:50.

Greg

mvallevand
2007-10-17, 03:34 AM
Greg, it ran perfectly until 10:25 but then it logs like the actual heartbeat process stopped although I don't see the send of the heartbeat that caused this state, some log entries look to be missing. Later You can tell that the server is stuck as I suspected, because even though the gui refresh command is being sent from 10:50 forward, no YUV2 updates are being returned as happened last night.

Note that next time this happens hit the Go Ok combo. This restarts the heartbeat process. I have not not found that it causes GBPVR to unstick itself or it would be automatic.

The matching GBPVR logs would come in really handy.

Martin

mvallevand
2007-10-17, 05:11 AM
Greg, because your capture actually lost the stdout redirection that you were aving very briefly I did think of an error trap that could help in real network error conditions. As a result I've updated the alpha dongle/mvpmc set.

Thanks for the help so far.

Martin