Unable to play certain albums via Albums option
Beantwortet
I’ve had my Bluesound Node 2i since February 2020. All my music is in FLAC format stored on a NAS drive. A Synology DS220+ 4Tb in RAID1. The share works perfectly on both an Android app and an iPad one.
Since an upgrade to the firmware last June I cannot play certain albums from the Albums tab. Individual tracks from the Songs and Artist options work fine. I can even select a song on one of the affected albums, tap the three dots to the right and select Go to Album and the whole album is available to play.
But if I select Albums - Gladiator - for example, I get the message saying “Couldn’t load content. Please try again”. It simply will not play. There are at least 10 Albums affected.
I raised a ticket with support four months ago and the issue is still not fixed. Even after I described how to get access to the Album via Songs. Surely it can’t be that difficult to fix.
The same happens on a five year-old Android smartphone and a two year old 5th Gen iPad. I really do want this fixing. Am I alone in having this problem?
-
Offizieller Kommentar
UPDATED OFFICIAL COMMENT
Thanks for your continued patience. The issue has been replicated by our Quality Assurance Team. Our Product Development Team has provided them with a fix which is being tested. It is being caused by a mismatch of metatags on the same album comprised of AlbumArtist, Composer, Album and/or Artist tag not matching when putting an album together to display. The issue has been long-standing but was exposed as we moved to the Players themselves serving the data rather than the Apps creating the display on the fly. Why you at first saw it on Android then it migrated to iOS a release later.
Look for a resolution in our next software maintenance update. That being said, given the logistics of navigating the busy holiday season and reduce risk and ensure reliability, it is likely our next scheduled release will not be before January 7th 2025.
Until we publish an update, please feel free to use Folder Browse to access the album in its entirety (assuming all tracks are listed in proper order in the same directory). Here's how; How do I browse my Local Library by folders or directories.
-
+1
1 -
@Max Dekker, thank you. 👍
0 -
Hi Ray
Thanks for your feedback. I can't say you are alone, but I can say you do appear to be in a very small minority as we are not seeing wide cases of this. That being said look for us to reach out to you via e-mail as I have asked our Support Crew to re-open your case.
Thanks for your patience...
0 -
Tony, I’ve had ongoing discussions via email for months. The support case shouldn’t be closed until it’s resolved.
The trouble is the team I liaise with aren’t the people doing the coding. It’s very frustrating.
0 -
Tony,
You do not seem to appreciate how badly this bugs affects the user experience. It affects many albums in my library and breaks the usability of BluOS' library functionality, which has now been utterly unreliable for half a year. BluOS is broken, because this and several bugs that do not get fixed.
Secondly, you seem to be sweeping this under the carpet, many others have complained about it.
Some facts about this bug:
- introduced around 30 May in Android app v4.4.0
- has been present in every Android release after v4.4.0
- is not present in Android app v4.2.4, irrespective of the BluOS release (4.2.x, 4.4.x, 4.6.x)
- reported in detail by me on 13 June (ticket 469537)
- confirmed by your team: "Following discussions with our Engineering team regarding your specific issue, they have replicated the issue in our labs."
- reported by Niels van Hoorn 5 months ago as well as various others (note this thread is about library, but someone hijacked it for an Amazon issue) in:
- reported by Jari Vihanto 3 months ago in:
https://support1.bluesound.com/hc/en-us/community/posts/25439750748311-Service-Unavailable
- reported by JC 2 months ago in:
https://support1.bluesound.com/hc/en-us/community/posts/26548891664151-Bug-in-Node-Library
- remains unresolved after half a year, despite the fact that you have the code that works laying around (Android 4.2.4)
The above suggests that your development team seems to be totally lost.
1 -
Gerben, thanks for your contribution. I had a quick look through the first link you provided where you said this… “ Apparent cause: this happens to albums that have in the metadata
1. An album artist, AND
2. An artist that is the same for each track of the album”I have a couple of manually created albums from DAT recordings and they’ve always been fine until June. One is a single track from “Also Sprach Zarathustra” by the LA Philharmonic conducted by Zubin Mehta. The single track is less than 4 minutes. That also fails to play via Albums.
0 -
I’ve been sent an email with a link to download a test file. It requires me to login using my email address. But having done that I get a message saying “Unable to get login information “.
How are we meant to get access to this site? No option to register.
0 -
Hi Ray, please continue to work with our Support Crew directly. They will be happy to assist.
0 -
I wondered why so many of my classical albums were affected. It’s clear now. All have the same artist for every track. Example is The Nutcracker by Berlin Symphony Orchestra. Conductor is the same. Composer is the same.
I would have thought this would make things simple to fix. Important too because classical music will be disproportionately affected. Have a look at the code prior to the June update. You do keep old copies of the code I trust.
0 -
Another affected album. The Planets, composer Gustav Holst, artist could well be the conductor of The London Symphony Orchestra, Sir Colin Davis. Same for all 7 tracks.
All the metadata is 100% accurate.
0 -
Hi Ray
Please continue to work directly with our Support Crew and update the request with your information. This way they can continue to work directly with our QA team to locate the root cause of your issue and resolve it.
Thanks for your understanding.
0 -
Tony, the information I posted is for the benefit of others experiencing this problem. Please understand this problem has been present for five months with zero progress. It’s only since posting here yesterday I’ve seen some progress.
0 -
Hi Ray,
Indeed the Zarathustra single matches my bug description in the other thread: "Affected are albums containing one or more tracks, thus including singles."
Another user had a correct addition to the bug report: if artist and albumartist are the same, the album opens correctly.
In the meantime I also found that if these albums are accessed through the albums listed under the albumartist, it fails, but if through the albums listed under the artist, the album opens correctly.
The official Bluesound comment above is rather shocking.
The only criterion being a minority is short sighted for various reasons:
- this specific bugs affects especially classical music, which will limit the number of users affected
- maybe a lot of users did not report, but simply resorted to one of the various workarounds suggested by other users
- Bluesound had confirmed this bug to be reproducible;
so it can be expected that every user, who has an album that has the metadata to trigger the bug, is affected - it ignores the severity of the bug;
opening an album is one of the most basic operations a user will perform;
personally, every album I play starts with opening it, which will show me the tracklist and other metadata, followed by hitting "Play all" - not fixing bugs, even if only reported by a smaller number of users, degrades the quality and user experience of the product
- bugs have no place in any decent piece of software
This does not stand on its own. One bug and was reported by me in January and two in June, all three could be replicated by Bluesound, none of the three has been fixed. The same is valid for various issues reported by other users. The "ghost share" bug has been around for years and must have wasted the time of numerous users.
Who is interested in multi-room, hi-res, Dirac, native DSD decoding, VU-meters or whatever, if basic functionalities are broken? I am not, which might make me a minority, which according to Bluesound logic can be ignored. For me, the reputation built by NAD over half a century has been destroyed by BluOS in less than a year.
All above is already bad enough, but it is even worse.
The official comment basically says that BluOS / Bluesound / NAD knowingly, willingly, deliberately choose for not fixing an identified bug, thus accepting that the quality of BluOS degrades and thereby as well degrades the quality and user experience of every Bluesound and NAD equipment that depends on BluOS.
1 -
Hi Gerben. It does appear classical albums are particularly susceptible to this problem. Hence why so few users are affected. We’re a dying breed! But that doesn’t mean it’s okay for the bug to remain.
I’ve also had confirmation a while back that the problem was reproducible. So why hasn’t it been resolved? As you say access to the Album via an alternative source is error free. I suggested they look at that code and use it on the Albums option.
I supplied a zipped version of the soundtrack to Gladiator. Some metadata was changed by Bluesound and I was asked to try it. Unfortunately it didn’t resolve the problem and in some respects was worse as every track was duplicated and played twice.
The reputation of Bluesound is on trial here as far as I’m concerned. The steps to reproducing the problem have been described as has a way of bypassing it. We’ve been extremely patient but patience has its limits.
I expect Bluesound to pull out all the stops now and fix what on the surface appears to be a straightforward problem.
0 -
To speak to both sides: -
The fact that an issue can be reproduced doesn't mean that it is immediately and easily fixable.
Firstly, diagnosis of the issue isn't always straight forward, even if it's easily reproducible.
What gets reproduced might even be a side effect of a different and more far-reaching issue. It's hard to tell, however, without a very thorough investigation.
Secondly designing a fix isn't always straightforward, either.
Sometimes, if the bug and its ramifications haven't been sufficiently analysed then a fix for one issue can easily break something else. Moreover, sometimes a fix might require very widespread and carefully considered changes throughout many tens of thousands of lines of code. Any such work therefore requires a lengthy impact assessment as an essential part of the design for a fix.
Looking at things from the other side, I'm not certain that going quiet and ignoring reported faults, or regularly appearing to blame the user's network or router are good policies either. (I’ve seen both behaviours here.)
I also have to ask whether any analysts, designers or developers are ever rotated into and out of the Support Crew. I ask this because some of the Support Crew members occasionally seem a little out of their depth, which is understandable given the rather complex and bespoke nature of the product that they're supporting.
Also, if the Support Crew and the Development Team are always kept separate then this risks creating a discontinuity and generating some failed communications since, in such a set-up, the Development Team will only ever be acting upon sometimes vague or inaccurate second or third hand information. And any such comm failures will inevitably be very costly to everyone.
0 -
Thanks for your feedback Ian...
You hit a lot of nails on the head here. BluOS, I am told with the new NANO and ICON releases, surpassed 2 million lines of code. This makes that oh-so-simple 'just 2 lines of code' harder to find and creates more of a domino effect when adjusted.
Network packets are getting better and more reliable over the 12 years since we launched BluOS but it's still not quite indoor plumbing or electrical like we have become accustomed to. As our products and other Smarthome tech (Ring, Lutron, Ecobee... are all products I have in my own home) result in upwards of 30 or even 50 simultaneous network connections, often all being fed by a lower-grade ISP router as part of your telecom contract, the first rule of IT 'reboot then call us back' which cleares the router cache and RAM stored network allocation table does solve a number of issues. Especially since BluOS does not use a central cloud partially for your privacy but just as much to ensure network sync reliability between players. I had to laugh myself as I had to contact one of those 3 I mentioned recently and the first response I got was 'try rebooting your router'.
We pride ourselves on being a listening company. Sometimes doing so can admittedly give a vocal minority the wrong impression in doing so. We can also make mistakes but can alter course to correct. It's one of the reasons Andrew H. (Our BluOS Product Development Brand Manager) and Matt S. (Our Bluesound Brand Manager) have been known to also post on this site. The three of us along with Gary S. (Our QA Co-ordinator who likes to stay behind the scenes) meet almost daily and sit in close proximity here at head office for the reasons you suggested...
Thanks for your patience and understanding... and of course for being a big fan of #LivingHiFi.0 -
@Ian Shepherd, interest post. Are you or have you been a programmer? I was before retirement so I have some experience when it comes to solving coding errors. The fact that selecting an album worked correctly for 4.5 years before breaking last June proves the coding was fine. Then something behind that option changed resulting in it not working under certain conditions.
The conditions causing it to “break” were reported some time ago. So all the programmer had to do was look at that section of code and compare it to the previous iteration. Good programmers will add comments to their code to explain some things.
The action of pressing the selected album is not millions of lines of code. Hard to say how many but not an insurmountable problem I would have thought.
Some code allows you to step through line by line so the line that causes the error should be easily identifiable.
I cannot understand why it’s taking so long to fix when the precise point and circumstances are known.
0 -
For 15 years I was, indeed, an analyst/programmer, and in one long-term contract I was also in charge of programming standards. The frustration was that adherence to those standards was very hard to enforce.
It's probably also worth remembering that a procedure or section of coding can suddenly go wrong without being changed at all because what has been changed are the conditions under which the code is executed, causing the code to be executed inappropriately.
At one place of work, there was an invoicing program that was used in over 50 countries, and each of those countries had its own specific requirements regarding what the program needed to do. As a result, there were fifty country-specific chunks of conditionally executed code to be aware of alongside the main core of the program.
If a global change had to be made, the logical thing to do would be to make one change in just the right place to make this change work for all geographies, but what developers tended to do was to chicken out and make 50 separate code changes, i.e. one per country. This approach meant 50 times the work, 50 times the risk of error, and 50 times the workload for the next global change.
So, really, code fixes should be simple, but human beings don't often allow it to be so.
Also, a bug might arise because some code wasn't changed when it should have been, or because that code wasn't considered when designing the fix.
Tisn't simple, tisn't.
0 -
Fifty changes? Arrgghh! Just allocate a number to each country in a master table and use that to determine the bit of code that needs executing with IF statements. Pretty simple really.
Back to this problem. Have you got any classical albums ripped from CDs? If so find one with all tracks by the same conductor or composer. Try playing it from Albums. It should fail.
Now select Songs and scroll down until you find a track on that affected album. Press the three dots on the right and select Go to Album. It will display the album cover and if you select Play All the tracks will play.
The code behind “Go to album” should be identical behind both commands. My guess is it isn’t.
0 -
I'll have to do a bit of work to ensure that I can create the correct conditions for the test, so that'll have to be domani.
0 -
Look forward to hearing back from you.
0 -
I've now tried to reproduce the problem, but I can't.
Firstly, I have to say that I can't recreate the exact conditions because my FLACs are all on my Bluesound Vault 2 and not on a NAS drive being accessed by a Node.
Secondly, I had to find a suitable album, and then tweak its metadata to ensure that track artist and album artist were the same for every track prior to re-indexing my library.
After that, I tried to select the album firstly from some search results, and secondly from the Vault's full list of albums.
Both selection processes worked for me and I could see and play the album and individual tracks as I wished.
I had also previously tested this album with blank Album Artist fields and it was fine for me then as well.
Sorry!
I suspect that a Node user would be a better tester.
0 -
Please see the updated official comment...
Some notes... the problem is model agnostic (It will happen on a NODE just as likely as a VAULT as it's the same process). To Ian's earlier point about 50 countries and SW development best practices... there are over 80 models of products BluOS works on...
Ironically this exact move was what exposed the problem as we were increasing reliability and speeding up response time to the Apps, not to mention reduce development time, by having the Players perform this lifting rather than the individual apps.
Thanks for #LivingHiFi
2 -
@Tony W, excellent news. Thanks to everyone in getting this bug fixed. Roll on 2025!
1 -
Thank you Tony for the open and honest update and also for the detailed explanation of the cause. It made an interesting and enjoyable read. (Honest!)
0 -
aw shucks...
0 -
OK, I won't gripe about how long it's taken to find out that my data is triggering this problem. Knowing the cause means I have a workaround until the fix is issued, for albums where it particularly bothers me.
For the classical ones it's not much of an issue at all because I very rarely want to play individual tracks. So I can either use Folder view or stay with Album view and use the album's menu to select "Play now" if I get the "Couldn't load contents" message.
For the remaining problematic albums I think I can randomly change the Artist tag on one track, provided I don't mind Artists view being less than 100% accurate, which I don't.
However, that brings me to the real point of this post. I have found one album (probably a lot more when I check) that has ID3v1 tags as well as ID3v2 tags. The ID3v1 set does not include AlbumArtist, the ID3v2 set does. Both sets have the same Artist on every track. On this album the AlbumArtist is the same as the Artist, which may or may not matter, but it does obscure what BluOS is doing with the metadata it finds.
So which set of tags is BluOS using to build its index? Does it create its own AlbumArtist if all the tracks have the same Artist? If it does, then my workaround might be better if I deleted the ID3v2 tags completely.
I've an idea there is an article somewhere that answers these questions but I couldn't find it.
0 -
The solution I have found is to download mp3tag (Its free), open the relevant folder in mp3tag, select all files, then the Artist and other tags can be altered to agree, then save and rescan the library.
0 -
@Homesteadric, is that advisable? I have CDs with correct metadata so it's the Bluesound software that needs changing, not the data supplied on the CD.
I have mp3tag and it's excellent software but it's not the solution this time.
0
Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.
Kommentare
53 Kommentare