search

owntone / owntone-server

Linux/FreeBSD DAAP (iTunes) and MPD audio server with support for AirPlay 1 and 2 speakers (multiroom), Apple Remote (and compatibles), Chromecast, Spotify and internet radio.
https://owntone.github.io/owntone-server
GNU General Public License v2.0
2.08k stars 234 forks source link

Play status updates broken by commit 2a61081 #205

Closed mike-seger closed 8 years ago

mike-seger commented 8 years ago

Commit 2a61081 breaks the play status in the following clients and probably all others too:

While a playlist of (FLAC) tracks is being played, the progress time does not update correctly and eventually ceases. On a track change the new track information is not shown.

It seems that Retune is affected the most by this.

Everything seems to work fine in da3d329.

ejurgensen commented 8 years ago

Thank you for the notification. Is this with the new config option enabled or absent/disabled? The latter is the default. I don't quite see how there can be a connection between the commit and the behavior you experienced, especially if you didn't enable the option.

I could not reproduce with Remote. Will try with Retune later.

mike-seger commented 8 years ago

Sorry, I made a mistake with the commit ids. I updated them and now the involved code changes really make sense for this issue.

couteau commented 8 years ago

I have the same problem with Remote, but I have not had time tried to figure out what the issue is.

On Sun, Dec 13, 2015 at 6:00 PM, ejurgensen notifications@github.com wrote:

Thank you for the notification. Is this with the new config option enabled or absent/disabled? The latter is the default. I don't quite see how there can be a connection between the commit and the behavior you experienced, especially if you didn't enable the option.

I could not reproduce with Remote. Will try with Retune later.

— Reply to this email directly or view it on GitHub https://github.com/ejurgensen/forked-daapd/issues/205#issuecomment-164308418 .

ejurgensen commented 8 years ago

I did my best to produce this error, but it doesn't seem to happen for me. I tried Remote and two instances of Retune (older Android versions). Staying true to the description I even tested with a FLAC playlist. So there must be something more to it. Here's a few questions to help me reproduce:

  1. What platform?
  2. libav or ffmpeg? Which version?
  3. Airplay or local audio?
  4. Suspicious log messages?
  5. Anything else?
couteau commented 8 years ago

I'm on debian stretch with ffmpeg 2.8. Output is to an Airplay device (I don't have local audio to test). I haven't had a chance to investigate the logs, but will try this weekend.

I have a suspicion it may be ffmpeg-related. I' had been on libav for a long time on Ubuntu Trusty with no problems, but recently had to reinstall after a failed upgrade, and decided to go with Debian, which uses ffmpeg. I at first thought it might be because debian comes with libevent 2.0, but I built and installed libevent 2.1 from source, and the problem didn't go away.

On Mon, Dec 14, 2015 at 1:21 PM, ejurgensen notifications@github.com wrote:

I did my best to produce this error, but it doesn't seem to happen for me. I tried Remote and two instances of Retune (older Android versions). Staying true to the description I even tested with a FLAC playlist. So there must be something more to it. Here's a few questions to help me reproduce:

  1. What platform?
  2. libav or ffmpeg? Which version?
  3. Airplay or local audio?
  4. Suspicious log messages?
  5. Anything else?

— Reply to this email directly or view it on GitHub https://github.com/ejurgensen/forked-daapd/issues/205#issuecomment-164516484 .

mike-seger commented 8 years ago

I'm running on Ubuntu 15.10 now (after an upgrade) and previously it was 15.04. I have another installation running 16.04. The problem occurs on all versions. All forked-daapd versions since 2a61081 show the issue. The following ffmpeg libs are installed: libavcodec-ffmpeg56:amd64 7:2.7.3-0ubuntu0.15.10.1 libavdevice-ffmpeg56:amd64 7:2.7.3-0ubuntu0.15.10.1 libavfilter-ffmpeg5:amd64 7:2.7.3-0ubuntu0.15.10.1 libavformat-ffmpeg56:amd64 7:2.7.3-0ubuntu0.15.10.1 libavresample-ffmpeg2:amd64 7:2.7.3-0ubuntu0.15.10.1 libavutil-ffmpeg54:amd64 7:2.7.3-0ubuntu0.15.10.1 libpostproc-ffmpeg53:amd64 7:2.7.3-0ubuntu0.15.10.1 libswresample-ffmpeg1:amd64 7:2.7.3-0ubuntu0.15.10.1 libswscale-ffmpeg3:amd64 7:2.7.3-0ubuntu0.15.10.1

The audio is local. No suspicious log messages - at least in the default log level. In the meantime I also tested mp4a (alac) with the same effect.

If you still cannot reproduce and we run out of ideas, I will test other platforms in vbox and if I can reproduce, I will provide a vbox image < 2GB with the complete "case".

ejurgensen commented 8 years ago

Ok, great to know that we can do that if all else fails.

I was testing with libav, and you are both using newish ffmpeg, so that will be the first thing I will look into.

@mike-seger could you test if the problem also exists when you use AirPlay? If you don't have an actual device, then maybe you could try with Shairport.

Another question: Does the problem appear right after playback is started?

mike-seger commented 8 years ago

Yes, the issue occurs with Airplay devices too (tested AppleTV) Also, the play status is broken immediately - forked-daapd streams to the device, but the remote just doesn't get it.

For perfect reproduction I just went ahead and created an ubuntu xenial server with forked-daapd from scratch. It contains a single playlist with some hopefully legal sound from youtube to test. The server has two users (root/developer) with the same password "test". You can just check their bash histories for more details. It also comes with the "broken" forked-daapd by default, but can be easily switched to the last good one by doing "make install" in developer@xenial-server:~/git/forked-daapd-da3d329 I'm about to copy the "Open Virtualization Archive" to a private location, as I don't want everyone to create traffic on my server. It shouldn't take you more than 5 minutes with Virtualbox and "Import Appliance" in order to set up the server and finally reproduce the issue.

@ejurgensen Please find the URL in your E-Mail. (download size is 1.1GB)

mike-seger commented 8 years ago

@couteau btw thanks for joining. Combining forces is always helpful.

ejurgensen commented 8 years ago

Wow, that is really great! I am almost sorry to tell you that I actually was able reproduce the problem yesterday, before I got your message. It was on a Debian Stretch vm that I created. This was with ffmpeg, but after seeing the problem I am not sure it is related to that. I think the problem may have been there when I tested with libav too, it just wasn’t very evident. It wasn’t immediately evident on Debian Stretch either, at first Remote and Retune seemed ok. It wasn’t until I had two Remotes in action at the same time that I noticed that play status is actually broken, just like you said.

Being able to reproduce the issue, and with a good pointer from you to a possibly faulty commit, I’m optimistic that I can make a fix soon enough.

mike-seger commented 8 years ago

Good to hear you could reproduce the issue and are optimistic about a fix. No big deal about the vm. I'm sure it will help me (and maybe you too) sometime in the future.

ejurgensen commented 8 years ago

As you can see, I believe the issue is fixed now. It was related to new versions of ffmpeg, where some initiations would fail, and the resulting cleanup triggered a bug in the inter-thread notification system. This broke play status updates, as it relies on the notification system.

I have still not fixed the failing initiations with ffmpeg, but they are not so critical. They only effect those few users, who want to use the new mp3 streaming feature.

mike-seger commented 8 years ago

Thanks for the quick fix - I tested OK