My Book Live sending wrong artist id3 info to iTunes?

Hello,

I just set up My Book Live on my network & put all of my iTunes songs on there. When I open the shared library, all the artists are wrong. Instead of showing the artist/group, it shows the composer. When I look at the folders through the back end, they are labeled correctly.

I’m running Mac Book Pro.

Any ideas how to fix?

Thanks, Jennifer

It may be that the ID3 tag format is wrong or out-of-date for how the WD iTunes server is reading this.

I’m not having that issue on mine.

Here’s a screenshot from MP3TAG showing that some of my files have a different composer than artist:

ARTIST:  Phil Collins

COMPOSER:   Phill Collins/Lamont Dozier

… and here’s how iTunes shows it:

It shows the ARTIST as “Phil Collins,” which is correct.   It is NOT showing the COMPOSER.

So, it may be as simple as updating your ID3 tags, as I did with MP3 a long long time ago (more than a year ago, I think…)

How can I tell if  my id3 tags need to be updated?  How do I update them?

Thanks,

Jennifer

I use the program called MP3Tag.

Thank you.  I will check into that program.

All you might need to do is just “Load” the tags, then SAVE them.   No need to edit anything.

Only do it with a few songs…  and then re-scan your iTunes server.

Let us know how it turns out.

This is a bug with both the WD MBL 1TB & 2TB disks and needs to be addressed asap as it pretty much makes your music collection unusable.  I’ve tested the same music collection on three disks, a 1TB MBL, 2TB MBL and a NetGear Ready NAS NV+ v2 with Firefly.  On both the WD MBLs the composer info is incorrectly placed in the artist info column.  Using the exact same music collection this does not happen on the NetGear ReadyNAS.

I wonder when WD will get this fixed…

 This is a bug with both the WD MBL 1TB & 2TB

Then, how come, as I demonstrated above, I don’t have this issue?  

Every one of my 10,000+ MP3s show the artist, not the composer…

Well, there could be several differences between your setup and mine which could be triggering this bug.  Here are a couple:

  • How did you rip your content? I used iTunes (various versions over the years)
  • What format is it ripped in? I’m using MP4
  • What firmware is installed on your disk? I have: MyBookLive 02.32.05-046 which is the latest.

1>  Lots of different ways including iTunes, going all the way back to “RealPlayer” days.

2>  MP3 and M4A, mostly  (which is the same as MP4 Audio)

3>  Same here…   and for several of the prior releases.   

Have you tried my suggestion above?

Interesting.  I’ve verified the embedded metadata using MusicBrainz Picard and, as expected, the data is correct.  I’ve tried altering certain tags and forcing a re-scan but it makes no difference, the WD MBL still mangles the metadata when viewed as a Shared Resource in iTunes.

 I’ve logged a support ticket with WD so hopefully they can get to the bottom of this. In the meantime, all my music is being served from my NetGear NV+ v2.

FatCandy wrote:

Interesting.  I’ve verified the embedded metadata using MusicBrainz Picard and, as expected, the data is correct.  I’ve tried altering certain tags and forcing a re-scan but it makes no difference, the WD MBL still mangles the metadata when viewed as a Shared Resource in iTunes.

 

 I’ve logged a support ticket with WD so hopefully they can get to the bottom of this. In the meantime, all my music is being served from my NetGear NV+ v2.

I don’t use my MacMini for ripping as cannot trust Apple to let me do things the way I want.

Using windows to rip my over 300 gigs of CDs into flac format, I’ve found problems with both the way a ripper works (or not) & the database the ripper obtains the tag info.  For example, atfter too late into my ripping, I’ve found that freerip for windows don’t always write the info correctly even when I edit & save the info as the editing is fully or partially ignored sometimes.

The databases are user entered like wiki & have found that one has to be quite careful & go thru what info was retrieved  as have seen that for a boxset, some CDs can have different titles instead of having the CD number; some entries even have different artists even if it is the same performer & some include the orchestra & conductor as part of the artist labeling & some even use the composer as the artist/performer.

Considering how Twonky does the groupings, I’ve even found many labeled as “unknown” for either type or performer.  Found that printing the listings of the “unknown” from Twonky’s html browser helped lots in figuring what goes where.

A problem with windows is the limitation of 256 bytes for path & filename but don’t know it the same applies to the Mac.  I’m using EAC in windows for ripping for more accuracy even if it is slower, but I still check things out before writing to the MBL; also a different CD database from freemp3.  The byte length limits will apply to selections where the id3 tag included the band/orchestra & album & composer for the artist name.

So, the short is the id3 tags problem is really either the ripper, CD database or whoever sent the entry to the database, or all 3.  Using the CD databases is good but one is also at the mercy of whoever made the entry; to be used with caution.  Unless one will tediously enter the id3 tags for each selection, album  which I did for some old recordings where no entries were found.

I fully understand the points you’ve made.  In this instance, however, there is a problem with the forked-daapd binary included in the WD firmware.  As I’ve explained already, the same music collection works perfectly well with Twonky on the WD MBL and works fine with iTunes on a different NAS (and hence different daap server).

Earlier this evening, I disabled forked-daapd on the MBL (which is included in the latest WD firmware) and configured & installed mt-daapd instead.  As expected, the metadata is no longer mangled in iTunes using mt-daapd and my music collection is usable once again. Yay.

Someone from WD should really take a look at either changing the daap server or fixing the existing bug.

Hmm.  Interesting “bind” they’re in.  The WD uses version 0.19, which is still the latest build, “officially.”  WD isn’t known for running a bunch of patches that require other regression tests.   

I’m surprised the project hasn’t released a new build in over a year…