Nightingale Forums

Full Version: Nightingale has started truncating my comment tag
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
I keep a lot of keywords in my comment field, for smart playlists. Suddenly, Nightingale has started truncating this field to 23 characters.

I have even gone back to mp3s I tagged with Nightingale previously, to edit the comment, and when I do this it truncates the field and I can't put it back the way it was.

Why has this happened, and how do I put it back the way it was? Thanks.
(07-23-2016, 02:16 PM)3×5 Wrote: [ -> ]I keep a lot of keywords in my comment field, for smart playlists. Suddenly, Nightingale has started truncating this field to 23 characters.

Weird. I can reproduce that on Linux x64 with Nightingale 1.13a, custom build from 20141116 (--with-taglib-source=packaged), with mp3 files, although it seems to clip at 28 characters for me. It does not happen with flac files (for me). What's even weirder: the tags in the file are not updated with the new comment. I did not check what happens if comments are already present in the file.

I have no idea what broke here (and sadly no time to properly debug this issue), did the comment field work for you in the past? If so, did you change anything (updated Nightingale, your system's taglib, ...)?
I'm not sure if I did change anything. I'm still using the standard repo, so at some point I probably upgraded nightingale in the last 3 and a half years and the upgrade broke this.
OK, do you have a way of determining when it was working? I'm not sure where to find old debs now.
(09-03-2016, 01:30 AM)3×5 Wrote: [ -> ]OK, do you have a way of determining when it was working? I'm not sure where to find old debs now.

I don't know if there are old builds available, but if you can build by yourself the easiest way would be checking out some old commits from before 2014, and checking whether the issue is present there (note the commit id!). Then, build a more recent verify the issue is there (note this commit id as well). Afterwards, you could use git-bisect to find the single change that triggered the bug, between the two commit ids you noted. That way, we know exactly when it broke, and are likely to also figure out what broke.

Build instructions are available on the Wiki: build:linux.