PDA

View Full Version : Running Asset under Wine on Linux



ocoro02
04-03-2010, 06:02 AM
I've been running Asset uPNP for quite a few months now under Wine on Ubuntu. It works pretty well - except I've got a few problems which I think only Spoon can probably give answers for as I think I may be the only person trying to do this!

1) Detecting changes/rescanning is haphazard. For some reason I need to restart the server in order to trigger either of them. This isn't a huge problem for me except ...

2) A restart very rarely fails to start the server again properly. I can see using lsof that normally it has a TCP port 26125 listener running. After a restart the process (Asset-uPNP.exe) is running but it's not bound to port 26125 (and nothing else is either - there's no stray processes still running for instance). This is very likely to be a Wine problem as opposed to an Asset problem. I have to reboot the box to fix it (!)



My questions are -

* How is a rescan/detecting changes command communicated to the server? I notice on a server restart (in the debug log) that usually it seems to detect the MediaFoldersWatch.txt file has altered and therefore triggers a 'detecting changes'. Is this the only mechanism or is most communication done through inter-process communication (I can see various pipes and sockets open)? The server & library status appears to be communicated to AssetConfig fine so it *seems* to all be working as it should.

* Are the circumstances under which the server (Asset-uPNP.exe) would close the port listener? Would it do this during a rescan/detecting changes?

Spoon
04-03-2010, 06:12 AM
It is very simple, a file RescanALL.bin or RescanRefresh.bin is created in the %appdata%\dbpoweramp\umedialibrary folder.

ocoro02
04-03-2010, 06:20 AM
And the server polls that folder for the existence of either file right? Simple and effective - which is a good thing! I'll have a play.

Spoon
04-03-2010, 07:15 AM
It watches the folder for change notifications.

ocoro02
04-03-2010, 02:12 PM
OK, I'm getting closer to the restarting Asset problem. Connections are in fact being held open (in LAST_ACK state) on the asset server host. This occurs when I've played tracks on the DS (and maybe removed them from the playlist or left them there) - basically when there's data in the Send-Q (viewable in netstat). These hang around for quite a bit - a few minutes (probably 5 at a guess). Now if I shutdown Asset within those few minutes, these LAST_ACK connections hang around forever. when the Asset server is shutdown, there's no processes left running, but the network connection is held open.

Here's an example with Asset still running (.11 is the DS, .2 is the Asset server). I

*blooper* netstat -an | grep 26125
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:26125 0.0.0.0:* LISTEN
tcp 1 35873 192.168.0.2:26125 192.168.0.11:1046 LAST_ACK
tcp 1 35873 192.168.0.2:26125 192.168.0.11:1042 LAST_ACK


Gonna post something on the Linn board because I'm not convinced the DS is behaving correctly.

Spoon
04-03-2010, 02:41 PM
If Asset is closed, then all connections should close, even if the remote host tried to keep them open.

ocoro02
04-03-2010, 02:45 PM
I'd certainly like to think so! It certainly is the case that Asset (well the Linux box) is still waiting for a LAST_ACK or two from the DS player though and is not receiving it. This is so low level as to be rather unusual. It could well be a problem on the Linux box, or with Wine and the way it interacts with the network interface.

ocoro02
04-04-2010, 01:27 PM
I'm pretty sure this is a problem with Asset on Linux/Wine now. I tried the same experiments with a Windows install and everything works as it should.

chrisrd
04-05-2010, 02:09 AM
OK, I'm getting closer to the restarting Asset problem. Connections are in fact being held open (in LAST_ACK state) on the asset server host. This occurs when I've played tracks on the DS (and maybe removed them from the playlist or left them there) - basically when there's data in the Send-Q (viewable in netstat). These hang around for quite a bit - a few minutes (probably 5 at a guess). Now if I shutdown Asset within those few minutes, these LAST_ACK connections hang around forever. when the Asset server is shutdown, there's no processes left running, but the network connection is held open.


Under Unix (and therefore of course Wine) the socket requires a 'close()' call to shut it down, e.g.:

http://forums.devshed.com/c-programming-42/closed-sockets-end-up-stuck-in-last-ack-590038.html

This may or may not be something Spoon wants to put into Asset to support operation under Wine!

Cheers,

Chris.

ocoro02
04-05-2010, 02:19 AM
Good stuff Chris - I do suspect this may be the case. I was quite interested in this particular issue as I used to deal with sockets on various flavours of Unix a long time ago and it rang a bell!

Apart from this issue, it's pretty good running Asset in Wine. It requires a few extra dlls to get radio to work properly but it all generally seems to work OK. I'll write up a how-i-did-it at some point.

ocoro02
04-06-2010, 03:16 AM
Spoon - do you think the addition of a close() on the necessary socket is possible or do-able in (say) a test build? I don't know how relevant any of this is to your code as I have no idea even what it's programmed in - could be opening a porting can of worms!

Just a reminder - check out the link Chris posted above as this sounds like what's happening:
http://forums.devshed.com/c-programming-42/closed-sockets-end-up-stuck-in-last-ack-590038.html

Spoon
04-06-2010, 03:30 AM
We do call socket close.

ocoro02
04-06-2010, 03:36 AM
Oh rats - it's something else then ...

ocoro02
05-29-2010, 04:17 AM
Reviving this thread as I've been doing some more investigation.
It looks like there is a problem with the way a particular situation is being handled with Asset running under the Wine emulator.
When a music track is placed on the playlist, a socket is opened and a certain amount of data from the track is buffered by the DS player - presumably to determine track details such as duration etc. When the track is played, a seperate socket is opened for the data stream. It's the original socket which passively closes - goes into CLOSE_WAIT, LAST_ACK, and then (in theory) the server receives the LAST_ACK from the DS and closes the socket.
On Windows the LAST_ACK is received and the socket closes. Under Wine/Linux, that LAST_ACK doesn't appear to be received. I've run a a tcpdump trace to see whether the host computer is receiving it - it looks like it is, so this must be a (quite fundamental) failure in Wine's handling of the network connection. I've spent some time trying to use library overrides etc. in Wine (and trawl the internet for similar cases) with no luck.

Message to Spoon - is it possible to workaround this problem in Asset and actively close that initial 'information' connection? I realise this is working round a problem in wine - but this may have exposed an edge case in Asset which could maybe be handled better with an active close().
Failing that - or rather, ideally - how about a Linux port of Asset :smile2:

Spoon
05-29-2010, 09:28 AM
The socket implementation is not our own, rather deep in the framework we are using (like MFC, etc).