Playback history / Last.fm scrobbling / dropout issues when streaming to a Wiim Mini

🖥️ Audirvāna Studio
,
1

I’ve been experiencing issues with tracks not being added to my Playback History in Audirvana Studio. I only noticed it because those same missing tracks are not being successfully scrobbled/saved to my Last.fm feed.

When the problem occurs, it usually happens after a few songs have played and successfully scrobbled. After that, the tracks will continue to play as usual, but do not appear in the Playback History. They also appear as “Now Playing” if I am looking at my profile page on Last.fm in real time, but once the song is over, the scrobble doesn’t get saved.

I’m curious if this may be a UPnP issue, as I only started to notice it last spring when I was experimenting with streaming via UPnP to another local computer. Then later I got a WiiM Mini, which is what I use exclusively now, and the problem is still intermittently present.

Some of the issues I describe above remind me of what @Djm1960 and @Agoldnear were discussing in this thread: Reoccurrence of UPnP track truncation and playback stops , which is why I wondered if the problem was UPnP-related or specifically having to do with the connection between the Audirvana Mac Mini and the Wiim Mini. I never recall having this problem back when I played directly from the computer to a local audio device.

Additionally, I’m occasionally experiencing a problem where playback will stop altogether. I run Audirvana Studio on a 2014 Mac Mini where it is the only application running. When playback stops, I will access that Mac Mini via screen sharing and find that the “current track” being displayed is one that had played 2-3 songs ago, and the Play/Pause/etc. buttons will not respond until I restart Audirvana.

Any help troubleshooting these issues would be greatly appreciated! I’ll be glad to share any necessary logs that may be helpful.

2

Wanted to follow up with some additional info. I was just reading a thread by @happydaze59 on Wiim’s forum:

They were experiencing the same issue where tracks are not being recorded to the Playback History. They wrote:

“When I play a high-resolution audio file within a playlist (higher than 44.1 kHz / 16-bit) via these WiiM devices, Audirvana often fails to record the ‘last play’ event for that track. When this occurs, no ‘Last Play’ events are recorded for any subsequent tracks that are played, even if they are standard, 44.1 kHz / 16-bit tracks.”

I went back and looked at the playlist that was playing when I most recently observed the problem, and it turns out this was possibly the case for me as well. Audirvana had been playing a series of files with alternating sample rates — 44.1 kHz / 16-bit, 48 kHz / 24-bit and 96 kHz / 24-bit were all represented. Then a handful of 44.1/16 tracks played.

The first track in the playlist that wasn’t added to the playlist history was 44.1 / 24, and no tracks were documented after that, even as the rest of them were all 44.1 / 16.

3

This article from the Audirvāna Knowledge base might shed light on this behavior:

The WiiM devices support DNLA transmission protocol… Audirvāna uses UPnP transmission protocol.

:musical_notes: :eye: :nose: :eye: :musical_notes:

1 Like
4

My knowledge of all of this stuff is limited, but from what I understand, DNLA is moreso a certification that particular devices can support certain protocols, UPnP being one of them.

While I have no idea what might be going on behind the scenes that causes tracks to not get logged, it seems like it might be some kind of breakdown during the “handshaking” process between Audirvana and the Wiim Mini, and once broken, audio must be stopped and restarted — and maybe even the app rebooted — to get it going again. The fact that I see missing songs on both the Playback History and on Last.fm points to the problem being on the Audirvana side. (Though obviously that’s just conjecture.)

5

How a transmission protocol is implemented by a manufacturer is not standardized… Audirvāna adheres to the UPnP protocol… if a manufacturer designs proprietary implementation in support of their devices, communication problems are created and it is in the court of the device manufacturer to change their code to more closely align with the UPnP protocols… How Audirvāna handles streaming interface anomalies may or may not, be something they are responsible for… you can submit a ticket here:

1 Like
6

In my experience this has to be an issue with the UPnP implementations of the various vendors and its interaction with Audirvana. I have observed this issue with varying degrees of severity with different endpoints as follows

  1. KEF speakers (LS50 WII and LS60) in approximately 30% of cases the final track and only the final track in a Play Queue fails to be recorded as played.
  2. With Devialet speakers several tracks in a play queue may fail to be recorded in approximately 90% of play queues over 6 tracks in length.
  3. With Chord Electronics 2Go streamers feeding these devices with digital output all tracks are ALWAYS recorded without fail.
  4. Both the KEF’s and Devialets do not have this issue if I play to them over Airplay only over UPnP.
  5. I do not believe it is a network issue as all my networks have tested well for latency and throughput and it occurs with my latest 10gbps all wired network recently installed. I have not had a playback interrupted for quite a number of years whether wireless or wired.

I have anecdotally noticed there are some tracks where this occurs more frequently than others but it does not seem specific to a particular file resolution.

As Audirvana has no control over a manufacturers UPnP/DLNA implementation perhaps they could look at an alternative method of recording tracks as played in the software. For those of us who experience this it is frustrating. In my case I spent several thousands of pounds on Chord equipment (2Go’s and 2Yu’s) to feed my active speakers a digital input to mitigate this issue…. (i decided it was way better option than using lossy AirPlay or using Roon……)

1 Like
7

Thank you for these insights! In my situation the Mac running Audirvana is on the other side of the house, but connected to a gigabit ethernet connection, then the Wiim Mini is connecting via WiFi to a router literally feet away from it. So I highly doubt local connectivity is my issue. I’d rather avoid a totally-local USB setup if I absolutely have to, because in the long run I am (was?) hoping to get a few more Wiim Mini devices, so that I can sync them within the Wiim app and have multi-room audio.

While I can only speculate, it seems odd that playback tracking would have lapses on both Audirvana and Last.fm, despite the Wiim Mini receiving the streamed audio. It leads me to suspect that some kind of end of file / start of file handshake hiccup is happening, likely UPnP-related, because why else would the song appear fine as “now playing” on both Audirvana and Last.fm, but then completely vanish once finished?

I’m going to leave logging on for the time being, that way the next time the problem occurs, I can report back if there’s anything identifiable in there.

1 Like
8

There is no status information being reported-back from the end-point over UPnP protocol…

Also, there is always a possibility that traffic on your network is causing interrupts… priority is essential… there are instances where security-cameras and wireless doorbells cause interruptions… maybe you need to put the end-point on a static-IP address… Also, Wi-Fi interference could also be at play no matter how close the end-point is to the router… anything like a cordless phone or other device that radiates RF/EMF could cause interference…

Also, ground-differential noise on the Ethernet network could also be at play if your system grounding scheme is not managed properly…

A simple-test of connecting the WiiM Mini directly to your Mac via Ethernet or Wi-Fi will give you an operational baseline to trouble-shoot from…

:musical_notes: :eye: :nose: :eye: :musical_notes:

1 Like
9

Just for info, in the very early days several years ago I ran an Ethernet cable directly to the KEF’s from my MBP, the issue still occurred. Then thinking it might be my USB-C to Ethernet adaptor I repeated with a different adaptor same issue, different Ethernet cable same issue and finally, just in case it was my main MBP I rinsed and repeated the above with my test machine ( a seldom used MacBook Air) same result.

Whilst I recognise the validity of your statements, in my case this was not supported by my test results.

1 Like
10

I understand, and sort of remember the hoops you have jumped through… It may well be some steaming service interface issue… however, the fundamental UPnP protocols do not provide a feed-back loop regarding end-point status… So as you allude, protocol implementation is key in the QoS of the distributed signals.

2 Likes
11

Agreed. Just for further clarification I only use Audirvana with a local library. I browse on an iPad using the Qobuz app to decide which music I would like to purchase then download and install in my local library on my Mac. I subscribe to Sublime as the cost of the subscription pales into insignificance compared to the discounts you then get on download purchases.

Only reason I connect to Qobuz in Studio is that it populates the artist and album pages with reviews which on rare occasions I read….. not a normal use case for Studio but then as my wife points out my thought processes are anything but normal…….

2 Likes
12

Since my last reply I turned on logs, played back tracks until the problem occurred again, and now I’m digging through the logs. To simplify what I’m looking at, I cleaned out a bunch of repetitious lines from the log. When I look at the general vicinity of when the track history problem begins, I see errors like these:

[warning]: FLAC decoder: unexpected end of stream

[warning]: FLAC decoder recoverable error: FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC
[warning]: FLAC decoder recoverable error: FLAC__STREAM_DECODER_ERROR_STATUS_BAD_HEADER

And another error which may or may not be related:

[error]: Audio file fingerprinter : error 400 for request with fingerprint of 6 bytes and duration of 2s : {“error”: {“code”: 3, “message”: “invalid fingerprint”}, “status”: “error”}

So for the moment I’m going to take your advice, @Agoldnear , and attempt to completely rule out intermittent WiFi as being part of the issue. If the problem is still present after that, I’ll drill down further.

13

Hi guys, quick question about this, does it happen when you are at the end of a playing album and get recommended tracks playing?

14

Hi @Antoine. For me no. I have the autoplay feature in Qobuz turned off. I only play local files in Studio. No idea what causes it or why it is worse with Devialets (common occurrence and can occur at any point in the queue) than the KEF,s (only ever the last track in a play queue) As stated previously it does not occur if I stream with Airplay. Only when streaming over UPnP to the speakers. Also this has never occured when streaming over UPnP to Chord Electronics 2Go streamers (which I now have several). Playback is flawless over UPnP with both the Devialets and KEF’s just that some tracks are not recorded as played in AS

15

In my case, no. Like @Djm1960 , I have the autoplay turned off, and always have. However in my case, I’m streaming tracks from Qobuz when the problem occurs. (It may very well happen with local files as well — I’ll plan to test that.)

When I first started this thread a week ago, my most pressing concern was that my Last.fm scrobbles were not getting saved, and thus were also not showing up on my Listenbrainz feed, which was synced with my Last.fm feed. While I certainly would love to see this bug in Audirvana fixed, I can be totally patient as long as my scrobbling remains complete.

So I took the opportunity to code an AppleScript which scrobbled from Audirvana to ListenBrainz, and used that alongside the existing built-in Last.fm scrobbler within Audirvana. Here’s what I found:

First, I learned for the first time that scrobbles for “now playing” and for “song completed” are two separate API calls to ListenBrainz and Last.fm. This explains why I was seeing “now playing” activity on Last.fm, but didn’t stay in the Last.fm history once the song completed.

I was able to create the Applescript by taking advantage of the Applescript library within Audirvana — thank you for that! This also helped me to realize that even when the bug appears and the tracks quit saving to playback history within Audirvana, Audirvana is still communicating the correct “playing track artist,” “playing track title” and “playing track album” properties, which is how I got the script to work.

So what seems to be happening is that some kind of hiccup occurs in the logs, then when the following track starts on Audirvana, it does successfully play to the WiiM Mini, but there is no movement on Audirvana’s progress bar (which I have set to display as a waveform). The time on the track just sits at 0:00. If I click on the Pause button, the song pauses and the progress bar lights up to the correct position in the track. If I press Play again, playback history and scrobbling to Last.fm will go back to working for a song or two before usually hiccuping again.

It seems to me that the hiccup is causing Audirvana’s application/UI to momentarily lose connection to the playing track. Because as I say, Applescript continues to provide the correct info for the currently playing track, it’s just the UI and the progress bar that are stuck. And since the progress bar is stuck, Audirvana’s UI fails to know when the track has ended, and thus doesn’t save the track to history or scrobble it to Last.fm.

I could be off base about some of that, but that’s my best guess at this point. I’m going to try to recreate the error 5 or 6 more times, save all the logs and do a comparison between them to determine the unifying factors. Let me know if I/we can provide any more details.