Charmed Quark Systems, Ltd. - Support Forums and Community
Android RIVA Client: taRiva - Printable Version

+- Charmed Quark Systems, Ltd. - Support Forums and Community (https://www.charmedquark.com/vb_forum)
+-- Forum: Third Party Development (https://www.charmedquark.com/vb_forum/forumdisplay.php?fid=8)
+--- Forum: Android Related Products (https://www.charmedquark.com/vb_forum/forumdisplay.php?fid=24)
+--- Thread: Android RIVA Client: taRiva (/showthread.php?tid=6721)



Android RIVA Client: taRiva - sic0048 - 09-18-2010

Now I seem to get an error when I try to enter the cidlogadmin setloglevel /CQC/CQCRemVServer/CoreAdmins/Dawn CQCRemVComm Info command. I've attached a screen shot that shows the command line and error. I didn't get the error the first time I entered the command. I restarted the CQC server per Fonceur's request and I got the error when i tried to enter it after cycling the server.

[Image: RIVAdump.jpg]


Android RIVA Client: taRiva - Fonceur - 09-18-2010

sic0048 Wrote:Now I seem to get an error when I try to enter the cidlogadmin setloglevel /CQC/CQCRemVServer/CoreAdmins/Dawn CQCRemVComm Info command.
It's probably remembered even through the restart, which would be why it didn't like it...


Android RIVA Client: taRiva - sic0048 - 09-18-2010

Log sent. There is only 1 image on the first page. so I loaded the DVD repo screen as well before sending the log.

I hope it helps.


Android RIVA Client: taRiva - Fonceur - 09-18-2010

Dean Roddey Wrote:I'm not sure if the RIVA server really provides enough or enough useful verbose level stuff or not. There is a good bit in there, but it might not be what is useful. I can always put some more.
The only information I can see is:

Code:
09/18 18:19:12-whs, CQCRemVSrv, CRemVSrvImgListener
{
    CQCRemVSrv, CQCRemVSrv_ThisFacility2.cpp.1231, Info/App Status
    Got a connection from client at 192.168.1.X:56902
}
09/18 18:19:12-whs, CQCRemVSrv, CRemVSrvImgListener
{
    CQCRemVSrv, CQCRemVSrv_ThisFacility2.cpp.1231, Info/App Status
    Got a connection from client at 192.168.1.X:32995
}
09/18 18:19:12-whs, CQCRemVSrv, CQCRemVSrvWImgThr1
{
    CIDSock, CIDSock_StreamSocket.cpp.764, Failed/Lost Connection, Error: 5034/1022/0
    The connection was reset
}
09/18 18:19:12-whs, CQCRemVSrv, CQCRemVSrvWImgThr1
{
    CQCRemVSrv, CQCRemVSrv_ThisFacility2.cpp.1065, Failed/App Status
    An exception occured in the image download thread
}

So basically there is one connection, taRIVA considers that it got dropped, so reconnects for the next image and so on. Is there any way to see down to the ms, as there is like a dozen images queried in less than a second...


Android RIVA Client: taRiva - Fonceur - 09-18-2010

OK try version .72 and either send me the log collector report or paste the following part:

Code:
Starting Image Request.
Initiating Connection Operation to Host: 192.168.0.101 on Port 13517
Transmitting Message Header: [Unsigned Byte: 2e, Unsigned Short: 1, Unsigned Short: 3d, Unsigned Byte: 82, Unsigned Byte: f1]
Transmitting Message Body: [Unsigned Byte: 0, 20 90 39 33 13 255 72 41 73 90 185 59 175 137 0 6, Unsigned Integer: 28, UTF8 String: CQCRepo::\System\Hardware\Icons\Light On]
Received an image start, load = 18
Received Image_Start

The important question is if you get the Received an image start or not... If you do, then CQC did start sending something as it understood the query, if not it would mean CQC didn't like the query or somehow took too long to answer...


Android RIVA Client: taRiva - batwater - 09-18-2010

I got this in my CQC log with my last test...

Code:
09/18 19:56:54-ncc1701-d, CQCRemVSrv, CQCRemVSrvWThr15
{
    CQCRemVComm, CQCRemVComm_ThisFacility.cpp.171, Failed/Data Format, Error: 4002/0/0
    Got packet sequence number 66, but expected 66
}
09/18 19:56:54-ncc1701-d, CQCRemVSrv, CQCRemVSrvWThr15
{
    CQCRemVSrv, CQCRemVSrv_WorkerThread.cpp.1835, Failed/App Status
    An exception occured in the service loop of worker thread 14
}
09/18 19:56:54-ncc1701-d, CQCRemVSrv, CQCRemVSrvWThr15
{
    CQCRemVComm, CQCRemVComm_ThisFacility.cpp.153, Failed/Data Format, Error: 4001/0/0
    Got an invalid packet header, recycling connection
}
09/18 19:56:54-ncc1701-d, CQCRemVSrv, CQCRemVSrvWThr15
{
    CQCRemVSrv, CQCRemVSrv_WorkerThread.cpp.1835, Failed/App Status
    An exception occured in the service loop of worker thread 14
}
09/18 19:56:56-ncc1701-d, CQCRemVSrv, CQCRemVSrvWThr15
{
    CIDSock, CIDSock_StreamSocket.cpp.822, Failed/Not All Data Read, Error: 5014/0/0
    Could not read or write all requested bytes
}
09/18 19:56:56-ncc1701-d, CQCRemVSrv, CQCRemVSrvWThr15
{
    CQCRemVSrv, CQCRemVSrv_WorkerThread.cpp.1835, Failed/App Status
    An exception occured in the service loop of worker thread 14
}
09/18 19:57:09-ncc1701-d, CQCRemVSrv, CQCRemVSrvWThr15
{
    CQCRemVComm, CQCRemVComm_ThisFacility.cpp.171, Failed/Data Format, Error: 4002/0/0
    Got packet sequence number 67, but expected 67
}
09/18 19:57:09-ncc1701-d, CQCRemVSrv, CQCRemVSrvWThr15
{
    CQCRemVSrv, CQCRemVSrv_WorkerThread.cpp.1835, Failed/App Status
    An exception occured in the service loop of worker thread 14
}

Note the sequence error got packet sequence number 66, but expected 66???

corresponding android log

Code:
Log Collector version: 1.1.0
Device model: HERO200
Firmware version: 2.1-update1
Kernel version: 2.6.29-bc0d2cff
htc-kernel@and18-2 )
#1 PREEMPT Wed Apr 14 23:16:01 CST 2010
Build number: 2.27.651.6

09-18 19:57:56.414 I/Panel   ( 5792): Get image:
CQCRepo::\System\Transport\Symbols2\Small\Left-1
09-18 19:57:56.424 I/Panel   ( 5792): Get image:
CQCRepo::\System\Transport\Symbols2\Small\Right-1
09-18 19:57:56.424 I/Panel   ( 5792): Get image:
CQCRepo::\System\Transport\Symbols2\Small\Up-1
09-18 19:57:56.484 W/dalvikvm(   90): disableGcForExternalAlloc: false
09-18 19:57:56.504 W/InputManagerService(   90): Window already focused,
ignoring focus gain of:
com.android.internal.view.IInputMethodClient$Stub$Proxy@44a7c9d0
09-18 19:57:57.924 I/Panel   ( 5792): Press at: (307, 333)
09-18 19:57:58.884 I/Panel   ( 5792): Release at: (308, 339) for a duration
of 966
09-18 19:57:59.434 I/Panel   ( 5792): Press at: (317, 337)
09-18 19:57:59.734 I/TARiva  ( 5792): Handler got a bundle
09-18 19:57:59.734 I/RivaClient( 5792): Sending to the server: PRESS
09-18 19:57:59.734 I/NetworkDispatcher( 5792): Writing PRESS
09-18 19:57:59.734 I/CQCOut  ( 5792): Transmitting Message Header: [Unsigned
Byte: 2e, Unsigned Short: 17, Unsigned Short: 4, Unsigned Byte: 78, Unsigned
Byte: f1]
09-18 19:57:59.744 I/CQCOut  ( 5792): Transmitting Message Body: [Point:
(317, 337)]


-Ben


Android RIVA Client: taRiva - Fonceur - 09-18-2010

batwater Wrote:Note the sequence error got packet sequence number 66, but expected 66???
Right, it has been pointed out before that something was off with that numbering... It's kinda like the CQCRemVSrvWThr15 which talks of "worker thread 14", there's a mix of 0-based and 1-based variables... Wink

As for the actual issue, maybe one packet got lost or something.


Android RIVA Client: taRiva - Dean Roddey - 09-18-2010

I thought I'd fixed that one off error in the numbering. I'll check that again. It maybe happening in another place, and insure that the exceptions get logged when in more verbose mode. However, if he cycled the service and couldn't get the command to work, then it never seemingly would have gotten into verbose logging mode. The RIVA client does wait a bit to come up, so that all of the drivers have some time to connect and such. So if you do it right after you restart, it will fail because the RIVA server is kind of waiting for the drivers to get happy.


Android RIVA Client: taRiva - sic0048 - 09-18-2010

It was at least 5 minutes after restarting the service before I tried those commands. I'd assume stuff doesn't take that long to come up, but I just tried it again without cycling the server and it worked, so I guess that was the problem.


Android RIVA Client: taRiva - Dean Roddey - 09-18-2010

Hmmm... I wonder if those are getting faulted in, and the remote setting of it isn't doing the fault in. So until something in the program accesses it and makes it fault it, it's not available. That's probably it, because the remote setting doesn't really now how to create the statistics item, only the thing that accesses it knows what it's supposed to be. So the server will probably have to force them to be instantiated on startup.