Out of sequence data over VPN, are we running UDP?

[dewdude]

So I've been fiddling with this small project of accessing my Asset install over a VPN on my phones LTE connection. UPnPlay not only allows WAN connections, but changing the user agent so I can pick various control point configs which is exactly what I want.

It has worked to varying degrees at various times. I play with it at various timea hoping I will get it working. The last issue I encountered involved constant dropping of my PPTP tunnel connection which was thought to be due to the fact my LTE network is IPv6 and has to tunnel 4. Likewise..my home connection is IPv4 only and I have to tunnel IPv6. Getting on IPv6 as listed as a solution...but OpenVPN came up a lot.

So Im currently running OpenVPN on my network and it solved a lot of problems...the tunnel connection now survives tower handof.

I now have another problem: random segments of music come in out of sequence...so it will skip around for about a second. Start playing a song..skip a second of audio...play for five seconds...play the previously skipped second of audio..continue as normal. It doesn't seem to be related to tower handoff becuase I can be sitting still and get it.

OpenVPN is running TCP....but is Asset running TCP? This feels like something I'd encounter with UDP packets coming out of order.

If anyone has suggestions it would be appreciated.

[dewdude]

Re: Out of sequence data over VPN, are we running UDP?

So I thought I'd give an update since I've gotten home and spent the past few hours playing around.

I have determined that I'm not actually getting data out of order...and that I am capable of getting uncorrupted playback through my VPN. When files are set to as-is, I do not experience any issues. It only seems to be when Asset has to encode to MP3 that I get a slight corruption. I have been able to determine this is about a half-second of audio from the beginning of the track, inserted anywhere from 3 to 6 seconds in. I have tried playing around with my UPnP client's configuration, but came up the same.

On a whim, I put the OpenVPN server back on UDP; which actually made discovery and loading faster than when it was on TCP. Play an MP3 as-is; perfect. Play a FLAC as-is; perfect. The only major variable from my previous configuration is my NAS. I suspect that, for some reason; pulling the files from a CIFS mount that likes to put it's physical disk to sleep may cause issues.

I have since connected my portable USB drive which contains a copy of all the music on my NAS and linked it to a virtual disk file. Asset is currently rescanning the library from this drive. I will see if this physically fixes any issues. As a last resort in case the USB drive is going to sleep and causing some data weirdness; I will copy some files to the virtualbox's "internal drive"...which should avoid any question of disk spin-up.

I should also mention I ruled out the VPN when I got the same corruption on WiFi.

[mville]

Re: Out of sequence data over VPN, are we running UDP?

Which version of Asset are you running and on which OS/platform?

Now, it could be that the Asset PC/device is not able to read the audio library or transcode fast enough for UPnP.

Start by testing with your audio library being local to the Asset Server and using a UPnP client connected with an ethernet cable to your network. Only when you have this working, can start to troubleshoot issues with the network, NAS, VPN etc.

[dewdude]

Re: Out of sequence data over VPN, are we running UDP?

Which version of Asset are you running and on which OS/platform?

Now, it could be that the Asset PC/device is not able to read the audio library or transcode fast enough for UPnP.

Start by testing with your audio library being local to the Asset Server and using a UPnP client connected with an ethernet cable to your network. Only when you have this working, can start to troubleshoot issues with the network, NAS, VPN etc.

I noticed this with Release 6 on Windows 7; Release 5.1 for Windows running on WINE under Debian, and R5.1.1 for Linux on Ubuntu. Let me explain the breakdown of each system and what resides where:

The Debian machine is a dedicated piece of hardware; 5.1 has been running under WINE on there for quite some time. It is actually connected to the same switch the NAS is hooked up to; so there should be zero reason it can't communicate fast enough.

My Windows 7 machine is my main desktop; it's connected via Ethernet to the gigabit LAN. It's able to push full rate to and from the NAS. It however stopped loading Asset after a configuration change and I have yet to reboot my machine to get it going again.

The Ubuntu machine is a VM running on my Windows 7 desktop; it was a very bare-bones server install untill I added OpenVPN, samba, and Asset. Music was mounted using CIFS, but it was later converted to use a physical drive in the form of linking a virtualdisk to it. This resulted in the same issue.

It took Foobar2000 a good hour to find anything on my network and a good two or three minutes to get it to play anything; but I did not have the same issues on any connection. I couldn't get any other Windows UPnP client to do anything but crash. It worked fine on the Debian machine which pulls over CIFS as well as the Asset running on the Ubuntu VM.

I can't figure out what the client would be doing to cause this on Asset encoded MP3s but not stuff that's already mp3.

[mville]

Re: Out of sequence data over VPN, are we running UDP?

Sorry, you've lost me.

Please specify what file format your audio library is, that Asset cannot transcode to mp3?

For testing purposes, I think you need to rule out your network completely. There are far too many variables and assumptions here, that make troubleshooting very difficult.

So, I suggest you go back to basics and start with the standard Windows 7 PC (with no virtual machines/OS, no network, no CIFS) running the latest Asset UPnP 6.1 beta. Put client software on this PC also (e.g. Asset Control) and a single album (from your audio library that you cannot transcode to mp3) on the local drive of this PC. Point Asset at this album and see if the client can play the transcoded mp3s. If not, we can try to work out why not.

Once you know Asset is configured and working correctly, you can then start to introduce your network, NAS etc. until the problem re-appears. That way we will know what is causing the issue.

[dewdude]

Re: Out of sequence data over VPN, are we running UDP?

Sorry, you've lost me.

You've lost me as well...I'm not going to keep running in circles 20 or 30 more times. I also think I fixed it.


The problem appears to be with the specific client. When I have Foobar play from any of the servers in any configuration...the MP3's come out fine. I thought I explained that in the last post. The problem is apparently not with any of my asset servers..or configuration...or network..or anything. I can take foobar...on my wifi network...and files transcoded to MP3 come out perfect. I'm not going to go through the hassle of shutting down my Windows machine to get Asset running just to try and use a buggy clunky UPnP client (because I'm in the middle of a project)

It is just on the specific client that when Asset is transcoding to MP3...I get a small section from the beginning that's inserted about five seconds in. So if you had someone speaking numbers every second it would come out like this:

"One - two - three - four - five - on- - six - seven - eight...."

I enabled caching of media. This seems to fix the problem. The only issue is playback won't start till it downloads the *entire* file.

Which, BTW, here's a list of formats in my library:

FLAC
APE (converted to FLAC when I find them though)
MP3
MPC
OGG
AAC/M4A
SHN (also converted to FLAC when I find them)
WAV (usually a mistake or unmastered project file)
DSD (doesn't stream, all in ISO format anyway)

So it's clear it's not necessarily a problem with Asset...but with the client itself. But it's still weird I only get skipping at the beginning when Asset is transcoding from any of the avilable formats and not when playing back an mp3 directly.