The VideoLAN Forums

VLC would not display CD information. I discovered that changing the CDDB server to "freedb.org" from "freedb.videolan.org" fixed the problem.

Here is the menu tree to change this setting:
Tools/
Show settings: All
Input / Codecs
Access modules
Audio CD

I hope others find this to be of value.

Hmm, that's annoying, we will check that...

We've noticed a similar problem too, except instead of no information showing we get incorrect information showing. Again the problem is fixed by amending to freedb.org

Is there a problem with the freedb.videolan.org link? A fix would be very useful as we're getting some hugely innappropriate results!

Thanks

Hi,

For me, the change has exactly one working and the titles of the tracks were displayed.

From the second start of VLC the titles of the tracks are no longer displayed.

That was with 2.0.8 and also in 2.1.1 that way.

kodela

Still broken in VLC/Win 2.1.3 and 2.1.5. I even tried doing a reset of the preferences, and it still ONLY shows track information the first time you insert a CD, then never can manage to look anything up after that. For that matter, it was showing ***WRONG*** information the only time it actually showed anything.

Really, need to find an AudioCD player for MSWin that's actually usable (at least for non-technical users like this machine has; all my *own* machines run Linux, so I can use Audacious for CDs).

I'm running "VLC 2.1.5 Rincewind" on Windows XP SP3, and have experienced the same issues that all you've described earlier...
Have also made some interesting findings about this ( applying debuging tools ) that I would like to share:

--Getting NO Results for Audio CD Tracks:
The biggest finding is that VLC, unlike all other CDDB-enabled programs that I've tested, seems very often to "miscalculate"
the Audio CD "DiskID" hash that is used to query and retrieve the Title and tracks info from FreeCDDB.org ( the most popular CD database ) and its mirros... This could explain why we get no CD info at all when replacing the default settings (freedb.videolan.org ) with the alternative : freedb.freedb.org , under:

VLC > Tools > show All > Inputs&Codecs > Access modules > Audio CD > CDDB Server


--Getting Wrong Results for Audio CD Tracks:
Using the default settings, VLC first tries to connect to freedb.videolan.org server, which in turn redirects it to this FreeCDDB mirror: freedb.musicbrainz.org.
Here I paste a typical query captured from the tcp connections stablished between VLC and the CDDB server:

GET /~cddb/cddb.cgi?cmd=cddb+query+b90fb70d+13+0+23216+50523+76836+93014+122908+141076+161343+186067+207190+224950+252362+27508

There, you can see the CDDB query, consisting of the calculated diskid hash ( see http://discid.sourceforge.net/ for a little program that can calculate this magic number for your Audio CD) followed by the exact lengths of all the tracks in your Audio CD ( for more details: http://en.wikipedia.org/wiki/CDDB and search for "CDDB protocol" ).

Then, it sometimes gets the right title and track info from the server, but most of the time we see wrong results displayed on VLC playlist for the CD tracks, Why is that happening ? Because when musicbrainz server ( acting as a freedb mirror, but unlike the real freedb.org server ) does not find an exact match for disckid hash and track lengths , it responses anyway (can you believe it! ), first with this warning code :

211 Found inexact matches, list follows

And then, VLC ask for the "inexact match" :

GET /~cddb/cddb.cgi?cmd=cddb+read+misc+00109f1e&hello=vlc+videolan.org+libcddb+1.3.2&proto=6 HTTP/1.0

And finally the CDDB sever responds passing the "inexact" CD title and list of tracks:

210 OK, CDDB database entry follows


So, as far as I have seen, VLC only gets the first two alfanumeric numbers wrong when calculating the diskid hash, but all other last six numbers seems OK ( compared with diskids calculated by other programs which retrieve CDDB info without issues, as "CoolCD Studio" for example, or by executing "diskid.exe" , which you can donwload from here: http://ufpr.dl.sourceforge.net/project/ ... 1.3.tar.gz ).

Shall do more research this week and tell if found something interesting. Regards!

Hi, all! Good news : As far as I have tested myself, we could say the CDDB issue is been finally fixed!

Untill there is a new oficial VLC stable release for download, in the meantime you could go and check it with a nightly build preview of VLC 3.0 :

http://nightlies.videolan.org/build/win32/last/


PS: Here you can see more of the research about this issue ( which I hope that it's solved! ):

https://trac.videolan.org/vlc/ticket/4370

Regards!

2.2.0 will have it too.

I use version 2.2.1 and had the same problem. Had to manually replace freedb.videolan.org with freedb.org and now this feature finally works.

freedb.videolan.org should redirect to freedb.org

Hi,
Sorry, I’m on OS X, but guess the issue doesn’t depend on the OS.

@JB: Thanks for replying here, that’s more than I’d have expected!
-> In short: The CDDB problem still exists in the 3.0 nightly.

Details (first from 2.2.2):

“freeDB.videolan.org should redirect to freedb.org”
Yes, it does, but the problem is still not solved (VLC 2.2.2),
at least with most of my (Spanish, original) CDs.
When CDDB is set to freedb.videolan.org the track info is wrong (from a different CD).
When set to freedb.org the details are correct (the info @ freeDB is OK).
Seems it’s not due to a wrong hash (see closed #4370).

Unfortunately on my system (OS X 10.9.5) it stores the CD info, so when I set the server back to …videolan… and insert the same CD the info will be still correct then.
After some testing I’ll be out of CDs with incorrect information.

Um.
I don’t understand - First it grabs the wrong data (via videolan) and keeps it, until connected directly to freedb.org. Then, once it got the correct info, it won’t accept the wrong data via the videolan setting - How does it know the formerly retrieved info is “better”?

This would mean it is still the same issue as reported by @fratto, it still accepts the “inexact matches” if there is no correct info available, but doesn’t accept it if there is better information stored already?

Also strange:
VLC asks (also) for port 80 of "images.l.google.com" (which I accepted)
but in (the Little Snitch)
connection listing I see (in red) "images.google.com" (connection broken, denied),
respectively “the rule does no longer exist”. The "images.l.goo... isn't used.

You’re asking for logs - Why don’t say how to retrieve what you need?
Google doesn’t know how to.
Do you mean from menu/Window/ Messages…?

Then I’ve tried the nightly 3.0.0-git Vetinari (Intel 64bit).

1)
(First I tried the CD which is not in the freeDB)
Originally set to freeDB.videolan.org the displayed data is the same wrong info as in 2.2.2 (inexact match?).
The request was to connect mb.videolan.org, but the (Little Snitch) reports 14 connections more, also a connection to freeDB.musicbrainz.org - The info at musicbrainz is totally useless, they don’t find most of my CDs, even when they are in the freeDB.org.

The next start of VLC requests images.l.google.com and reportedly connects to 15 different servers. Also the not connected (red) images.google.com (see above) - same as in 2.2.2.
Log file:
First there is no entry in the log file “messages” visible after start up.
But then, _after_ a click in the black window (???), suddenly it talks:
* matching “any”: 1 candidates *?

2)
Now I’ve changed the CDDB to the freeDB.org setting:
(Same CD which is not in the freeDB)
It asks to connect to freeDB.org, connects to 15 servers, but doesn’t display valid info, just “Track 01” and so on.

———

3)
Next a CD which is (correctly registered) at freeDB.org but displayed wrong info in 2.2.2 with the .videolan. setting, now in 3.0:
Same as with 2.2.2, the nightly 3.0 has wrong info (Chinese letters), a wrong CD content is displayed.

4)
Same CD, but now set to freeDB.org:
Asks to connect to freedb.org, displays correct track info, asks for mb.videolan.org, tools.google.com, t2.gstatic.com (why so many this time?) and Little Snitch shows connections to 15 servers in behalf of VLC.

5)
Same CD now, but back to the .videolan. setting:
VLC doesn’t ask for a internet connection, track title display is correct,
seems the data are stored internally as with 2.2.2.
Rem: I don’t think this is a good idea, just a gut feeling at the moment.

#########

Conclusion: Same problem as with 2.x exists in the 3.0.0 Vetinary,
using freedb.videolan.org any reply is accepted and displayed.
However, the 15 connections seem to be mad, too.

¿? Question:
a) Why not “simply” (I know, sorry) take the info from the “CD-Text” in case there is not a full match at freeDB?
b) Why not place a warning in case the CD-Text differs from the playlist?
c) Why not - with the consent of the user - upload the CD-Text to freeDB in case of a) ?

+++ Ups, there is one new issue in 3.0:

When playing, moving the progress slider back to the beginning of a track it often jumps to the next (or further down) track of the CD, didn’t have that in 2.2.2.
(3.0 seems to be much faster / critically responding in this mouse movement), probably an “old” issue broke through?

... Um, on ejecting the CD the titles remain in the playlist (why?).
Double clicking now on one track reveals the problem: Panic messages for this and each following tracks “Your input can’t be opened” - oh really?
I have to click 8x “OK”, tracks are still in the playlist (only 3 yellow warning triangles in the list, the 2.2.2 has all 8 ).
-> Old issue but still doesn’t make sense.

I love VLC ‘cause it’s straight forward compared to iTunes.
Thanks for reading, let me know if I could be of any further help (I have the "log" file if you need it).

Regards,
Miguel

I know it's been sometime since your original post. I also am having problems with cds that are not giving me correct info. Which database is better? Freedb.org or Freedb.videolan.org. Example, I have a Bobby Rydell Grt. Hits cd that gives me the group as The Little Series-Rise and Shine. LOL. What can I do, Please.Thanks, Harold

I have tried multiple server names, multiple ports, under both MSWindows and Linux. None of them work.

This has been broken for YEARS now. I'm not holding out any hope this will ever be fixed.

Hello, mortals - I COME FROM THE FUTURE! And yes, I registered just, only, and exclusively to note that "changing the CDDB server to "freedb.org" from "freedb.videolan.org" fixed the problem" for me too, in Win7/VLC2.2.4, in AD 2019 (deep bow to etienne53-san). Then again, seing as how I've long given up any hope of any bug in any open source software ever getting fixed, this is just par for the course. Caveat any users - yes, this is the solution you're loking for...

I have VLC v. 3.0.8 installed on a 64 bit Win 7 Pro SP1 computer with i5 processor and 8 GB RAM. I also have it installed on an up-to-date 32 bit Win 10 computer with an Intel Core2 Duo processor and 4 GB RAM.

The track name retrieval does not work on either computer, no matter what link is used.

This feature has never worked on windows. It's about time it got fixed.