Unable to play certain albums via Albums option
Answered
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?
-
Official comment
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.
-
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 -
I opened the app this morning and saw an update was available. I chose to install it immediately. Left it alone until the blue LED was lit. I opened my Album selection and selected a previously problematic title. I’m delighted to say it opened without error. Tried it on a few other ones and those too were okay.
Finally, i searched for song titles that have more than one artist. Unlike earlier they now play the correct version.
It’s taken seven months but I have a solution to this longstanding problem. I hope others are happy too. Thanks @Tony W. All’s well that ends well. 😁👍
2 -
+1
1 -
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 -
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 -
@Tony W, excellent news. Thanks to everyone in getting this bug fixed. Roll on 2025!
1 -
Yeah, Microsoft would break then abandon it I guess..
Ray - the CD ripper module within dBPoweramp 'handles' the metadata but all it is doing is recognising the CD from track numbers and lengths and pulling metadata from four different online databases (discogs, GD3, Musicbrainz & freedb) which are all maintained by public submissions and are generally ~90% 'correct' (correct as per the info supplied with the CD). The CD itself just has the audio on it, no metadata whatsoever unless it is a multimedia (non red book audio) CD which have the audio and a separate data track on them to be read by a PC and were cool for fifteen minutes in the 2000's.
I always open the metadata tab once CD ripper has recognised the CD and populated the metadata and tweak it using the CD as reference. Very, very rare there are no edits required and I have >15,000 tracks ripped from CD.
Also have >5000 tracks purchased and downloaded as digital media and rarely they are tagged appropriately or correctly also.
I am super anal with tagging..
1 -
Does anyone have a description of the rules BluOS uses when it processes tags? I have some notes on the subject that are several years old but I've no idea where I got the information from so I don't really trust them.
I'm hoping that better knowledge of this would help me find and "correct" the tags that are triggering the "Couldn't load content" error. I'm only planning to do this on albums I listen to a lot - the rest can wait for a fix in BluOS.
1 -
I have one version of "Astor Mo Chroi" on CD1 of the BBC "Bringing It All Back Home" album and another version of the same song on CD2 of the same album. When I use Song view, it lists them one after the other and it plays the one I tap on. The track numbers within each album are not the same, but I guess it would be too much of a coincidence if your three "The Power of Love" tracks were track 4, say, on three different albums.
Now if Bluesound could publish the rules they are using to build an index key from the tags they read off a file, we'd have some idea of what might be going on . . .
1 -
Hi Tony
The comments state it is about the meta tags in the Library, but I also get the problem when streaming from Tidal. Am I mistaken to think it should never happen with tags from streaming services?
I cannot influence tags from streaming services so cannot change those. I am also severely affected by this bug. I know a little about programming and if it is replicated it should be fairly easy to fix. Hope you will fix it very soon!
1 -
I've updated to iOS app 4.8.1 and BluOs 4.8.17 and all of my albums that previously triggered "can't load content" now open properly.
1 -
Node & Nano , using IOS (16.7.10) controller on IPAD
I still have the issue of "Content could not be shown" on most classical Albums, it seems like there is an corrolation with the metadata issue with Colon : in album name as all the albums with problems have that feature (my standard tagging for classical albums are "Composer: Album"), however it's not 100% conssitent as a few classical albums with : in the album actually works.
So "Beethoven: Violin Concerto - Haitink" cannot be show whereas "Arvo Pärt: Serenity - The Beauty of Arvo Pärt" works fine , both albums have the same artist and albumartist for all tracks.
1 -
Ran a quick test with the precise titles you mentioned, both open fine. All my albums with a colon in the albumtitle open fine as well. So not able to reproduce.
Have you tried whether the Haitink album opens, if you remove the colon from the albumtitle for each track, without changing anything else?
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 -
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 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
Please sign in to leave a comment.
Comments
76 comments