Closed GoogleCodeExporter closed 9 years ago
May I ask you to attach the output of the client, too. This happens if a client
sends out a discover request and multiple servers are responding. It should not
happen If you have only one server running in your network.
Original comment by rolmie@gmail.com
on 3 Aug 2011 at 7:15
I only have one tuner in the system attached to the server, a nano Stick 290e
DVB-T1/T2 usb device. There is no tuner on the client.
Both client and server are the binaries from the website. The driver was built
on the client from source downloaded from the web site.
The driver is loaded as shown by the following on the client:
$ lsmod|grep vtun
vtunerc 18497 0
dvb_core 90587 1 vtunerc
The output from the client is:
$ sudo ./vtunerc.i686 -f t
vtunerc: [1743 ../../vtunerc.c:386] debug: added frontend mode DVB-T as mode 0,
searching for tuner types 4
vtunerc: [1743 ../../vtunerc.c:390] debug: frontend switch: only one mode is
allowed. First is used
vtunerc: [1743 ../../vtunerc.c:485] debug: no server connected. discover thread
is 0 (DWS_IDLE:0, DWS_RUNNING:1)
vtunerc: [1743 ../../vtunerc.c:487] debug: changeing frontend mode to DVB-T
vtunerc: [1743 ../../vtunerc.c:509] debug: Start discover worker for device
type 4
vtunerc: [1743 ../../vtunerc.c:586] info: vtuner message!
vtunerc: [1743 ../../vtunerc.c:183] info: starting discover thread
vtunerc: [1743 ../../vtunerc.c:225] info: Sending discover message for device
types 4
vtunerc: [1743 ../../vtunerc.c:239] info: Received discover message from
192.168.1.14 control 46059 data 58035
------------------------------------------
Nothing more from the client after this.
The corresponding output from the server is:
$ ./vtunerd.x86_64
vtunerd: [2811 ../../vtunerd.c:76] info: S2API tuning support.
vtunerd: [2811 ../../vtunerd-service.c:35] debug: autodiscover socket bound
vtunerd: [2811 ../../vtunerd-service.c:261] info: waiting for autodiscover
packet ...
vtunerd: [2811 ../../vtunerd-service.c:265] debug: request received
vtunerd: [2811 ../../vtunerd.c:83] info: received discover request
vtunerd: [2811 ../../vtunerd-service.c:261] info: waiting for autodiscover
packet ...
vtunerd: [2811 ../../vtuner-dvb-3.c:57] info: FE_GET_INFO dvb-type:2
vtuner-type:4
vtunerd: [2811 ../../vtunerd-service.c:67] info: anon stream socket prepared 37
vtunerd: [2811 ../../vtunerd-service.c:302] info: control socket bound to 46059
vtunerd: [2811 ../../vtunerd-service.c:67] info: anon stream socket prepared 38
vtunerd: [2811 ../../vtunerd-service.c:315] info: session prepared
control:46059 data:58035
vtunerd: [2811 ../../vtunerd-service.c:133] debug: tsdata_worker thread started.
vtunerd: [2811 ../../vtunerd-service.c:318] debug: Answered discover request
vtunerd: [2811 ../../vtunerd-service.c:333] info: no client connected. timeout
vtunerd: [2811 ../../vtunerd-service.c:468] debug: wait for TS data copy thread
to terminate
------------------------------
Nothing more after this.
Hope this helps.
Original comment by tobizt...@gmail.com
on 3 Aug 2011 at 8:17
The above issue happens to me too, If I dont use like ex. w_scan within 1-2
seconds after vtunerd / vtunerc starts it looses the client with timeout, and
nothing happens after that.
If I do use w_scan within 1-2 seconds it holds the connection like it should
even after w_scan is completed.
Original comment by kriss...@gmail.com
on 3 Aug 2011 at 2:48
Hmm, it looks like this is blocking the client:
if (ioctl(vtuner_control, VTUNER_GET_MESSAGE, &msg.u.vtuner)) {
ERROR("VTUNER_GET_MESSAGE- %m\n");
exit(1);
}
I can reproduce this on x86_64 but not on DMM hardware. I suspect a issue in
the kernel module.
Original comment by rolmie@gmail.com
on 3 Aug 2011 at 8:46
This happens on my i686 client. I've started looking at the code area you
mentioned following it into the driver but as yet nothing obvious. Who
really needs to investigate this (possible) bug? Strange it's not shown
before.
Original comment by tobizt...@gmail.com
on 4 Aug 2011 at 10:05
HoP is qualified to have a look, but he might have no chance for the next week.
The issue is, that poll signals that there is a message outstanding, but ioctl
blocks then.
Original comment by rolmie@gmail.com
on 4 Aug 2011 at 10:36
Guys, when I return from holidays I have a look on it ASAP.
Unfortunatelly it will be after 21th August only.
/Honza
Original comment by jpetrous
on 4 Aug 2011 at 10:09
[deleted comment]
Hi,
> #!/bin/bash
> ./vtunerc.x86_64 -n xxx.xxx.xxx.xxx -f s2 &
> echo "asd" > /dev/dvb/adapter1/frontend0
this dosn't work for me. I guess we have to wait till jpetrous is back.
Original comment by rolmie@gmail.com
on 9 Aug 2011 at 7:11
Thats too bad, When I dont use the "echo" it never starts, when I do use it, It
always starts right
Im using vdr.
Original comment by kriss...@gmail.com
on 11 Aug 2011 at 7:33
As far as I can see from running some diagnostics, vtunerc.c line 552 polls 2
file descriptors and one returns, pfd[0]. At line 556 it calls ioctl for
VTUNER_GET_MESSAGE. This causes vtunerc_ctrldev.c to be entered and line 241 is
the case stmnt for VTUNER_GET_MESSAGE which at line 242 it calls
wait_event_interruptible(ctx->ctrldev_wait_request_wq,
ctx->ctrldev_request.type != -1); this never returns as the event is never
satisfied. In my tests this only ever gets satisfied by me doing Cntrl+C in the
terminal that ran vtunerc, ie it creates and sends a signal which cases the
wait_event to complete. As far as I can tell there is nothing being done at
the time of the wait_event for it to satisfy the condition, unless the other fd
polled back in vtuner.c, vfd should satisfy it. My line numbers are approx wrt
to the original source as I've added diagnostics statements to see what's
happening.
Original comment by tobizt...@gmail.com
on 11 Aug 2011 at 9:52
This issue was closed by revision f329d597bd62.
Original comment by jpetrous
on 24 Aug 2011 at 11:52
Interesting, google code is smarter me :-)
Bug status was changed immediatelly when I commited fix. It's creazy.
Anyway. The bug shloud be really fixed now. Please test and report back.
/Honza
Original comment by jpetrous
on 24 Aug 2011 at 11:57
Just a comment about how the web site is set up, when I click the revision link
I get "Error 404. The requested URL /p/vtuner/source/detail?r=f329d597bd62 was
not found on this server. That’s all we know." There seems to be something
wrong with switch over from the old DreamTuner web site to the new one: can it
be fixed?
Original comment by tobizt...@gmail.com
on 25 Aug 2011 at 7:59
Did you show me full URL in your comment? There should be repository name
inside URL string.
This is what I get if I click on current latest revision. And this is working
for me:
http://code.google.com/p/vtuner/source/detail?r=f329d597bd62e30e7294fb8a1b6c416b
a1b3bd79&repo=linux-driver
/Honza
PS: Next time, please, enter new issue, to not mix different things together.
Original comment by jpetrous
on 25 Aug 2011 at 8:14
Ok, I've run the updated driver and can report that it now works, with some
qualifications. Firstly I've not tested remote sound as my remote machine
doesn't have sound set up. Secondly, although it seems to work ok for standard
definition channels (UK), vlc reports a number of errors when viewing high
definition channels, (lots of dropped frames), I'm looking into this to try and
locate where the problem might be eg vtuner, vlc, LAN, cxd2820r driver etc (I'm
use a 50Mbs LAN for testing, ethernet over mains power, not WiFi). Also I'm
using a nano Stick 290e USB TV device with the (experimental) cxd2820r driver
(for UK HD TV which is DVD-T2). I'll report back after running some more
tests. Great improvement so far.
Original comment by tobizt...@gmail.com
on 30 Aug 2011 at 10:20
Original issue reported on code.google.com by
tobizt...@gmail.com
on 2 Aug 2011 at 12:26