Here I'll list issues I come across myself when using Giocoso or which others notify me about and that I can reproduce. If I've been able to identify any solutions or workarounds, I'll document them here too.
Q. Sometimes, when new music starts playing, the program display area shows a message along the lines of "convert-im6.q16: CorruptImageProfile `.../giocoso3/art/albumart.jpg' (XMP) @ warning
/profile.c/ValidateXMPProfile/1675." What does that mean? And what can I do to stop that appearing?
A. Confirmed as an issue:
The issue is not, technically, Giocoso's but to do with ImageMagick, the tool Giocoso relies on to do image processing. It has all sorts of policies regarding who is allowed to convert images, how big they can be and how much memory they are allowed to take up, for example. It is possible that the artwork you've associated with particular recordings is too big or has internal issues that don't manifest themselves in visual artefacts. The image in the above screenshot was a 1500x1500 pixel one, though, which isn't massive.
The file which governs these ImageMagick policies is /etc/ImageMagick-6/policy.xml. If your ImageMagick version is 7+, the folder name will be ImageMagick-7, of course. (Run convert --version to find out if your distro uses ImageMagick 6 or 7). Whatever its precise location, the file contains lines such as these:
You could try increasing some of these resource limits (by editing the file as root), but my specific values look sufficient to me: 256MB of memory should be enough to handle very large images; an image width and height limit of '16KP' means 16000x16000, which is about 100 times larger than the image which triggered the above error! So, if there are some limits you could increase, fine. If, as in this case, they seem fairly generous to begin with -it could just be a bug that ImageMagick has. They are not unknown, after all!
A more specific suggested reason and possible solution was mentioned here,
Over the last year we have added checks in ImageMagick to help prevent security issues (e.g. aborts, uninitialized values, integer overflow). One new check is that the XMP profiles are compliant. The exception you received suggests that your image has a XMP profile that does not validate.
Using this idea that an image's embedded metadata might be tripping things up, I tried to fix the earlier error I was experiencing with one of my own recordings as follows:
- Use Semplice in that recording's folder to extract the existing album art (to a file called folder.jpg)
- Use the command exiftool -all= -overwrite_original folder.jpg to remove all existing EXIF data from the image
- Use Semplice to re-tag the FLAC with the modified folder.jpg
...and when I then used Giocoso's Play Music menu Option 3 to play music from the specific folder, the album art displayed correctly, without weird warning messages:
So, in my case, it would appear that something was definitely amiss in the album art's metadata and it was this that was tripping up ImageMagick. Fixable outside of Giocoso, basically.
The good news is that however ugly the error message is when it appears, it shouldn't affect music playback at all -and the errors and generally screwed up display should resolve themselves when the next recording is played. You'll notice from the above screenshot, too, that the message is a warning, not an error: it didn't stop Giocoso correctly producing and displaying the appropriate album art+caption panel when needed.
Q. When I play music, the count-down timer thing in the top-right corner of the main display doesn't seem very accurate. Sometimes it stops several seconds short of the claimed duration before something new starts playing, though it sounds as if the whole recording was played. What's wrong?
A. Nothing, but it's a confirmed (and non-fixable!) issue. Here's proof: a recording that has ended 2 seconds before it was thought it would:
The 'pausing play for 3 seconds...' text tells us that this recording has ended and the 'pause between plays' timer has kicked in... yet the display in the top right-hand corner of the screen says that only 30 minutes and 10 seconds have been played of a 30 minutes 12 seconds-long recording. So you are spot on to observe that the countdown timer thing is not terribly accurate (I can confirm with my ears, which you'll just have to trust, that the entire recording was actually played: it didn't abruptly stop two seconds short of its final notes!)
So what's going on?
Firstly, there are rounding errors: if a track lasts 3 minutes 27.51 seconds, Giocoso will calculate it to be 3 minutes 28 seconds long. If you have multiple tracks making up a recording, that extra 0.49 seconds per track can start adding up to a claimed duration for the whole recording that's significantly longer than it truly is.
More problematically, the bit of the display that says 'how long has this recording been playing for' is computed in a loop of code that is meant to iterate every second. But if your PC is a bit underpowered (think: Raspberry Pi 4, for example, where this issue personally bit me hard!) and it suddenly has to do background housekeeping work, that loop starts taking a tiny bit more than a second to complete and that error can start to accumulate: the display will say 'you've played 45 seconds of music' and actually it's been 46 seconds: it's just that the loop to update the counter is running slow versus clock time. It can even work the other way round: if your PC's internal clock is less than perfect and has little to process in the background, it can skip through the loop in less than a second, making the 'you've played X seconds of music' display go faster than it should (though this is rarer than the 'running slow' scenario).
I actually wrote some 'clock correction' code to deal with this. By comparing the number of played seconds with the known number of elapsed clock seconds since playback began, Giocoso can sometimes 'jump' a second, or display the same seconds for an extra second, depending on which way it needs to adjust the counter. This actually works quite well: you should generally never be more than 2 seconds out, 'played time' v. 'of time', as a result of its continual clock-watching and counter auto-adjustment. On a reasonably fast PC, I find that the counter adjustment code rarely kicks in, anyway: "play v. of" discrepancies then tend to be entirely a matter of per-track rounding.
But notice how the counter adjustment works: it compares 'I have advanced the counter 50 seconds' with 'the clock time on the system has advanced 51 seconds since play of this recording began'. It therefore concludes, 'I need to jump the counter forward 1 second', which it will then do. The problem then arises: what if you now pause the playback for ten minutes? For then, the clock time will advance 600 seconds, but the 'played' counter is stuck at 50 seconds -legitimately, because that's what pausing playback means! When you resume playback, how can you know if the counter is 'out' any more? You cannot compare it to the number of clock time seconds since playback began any more, because that's now hundreds of seconds ahead of 'played' time! So the short version is, the moment you pause playback of a recording, Giocoso can no longer invoke the counter-adjustment mechanism: the 'seconds since play of this recording began' is now no longer a usable reference point against which to compare. As a result, if a play is paused, the auto-clock adjustment mechanism cannot be used upon playback resumption and ever-once-paused plays are therefore inevitably going to be many seconds, potentially tens of them, 'out' in their calculations.
I should just add that Giocoso will always play through to the end of a recording. The thing which triggers the move onto a new recording is the genuine end of the present recording, not the numeric values displayed in the countdown timer. So, yes: recordings will reach their actual, natural end even when the timer still says several seconds (or more) of playback are due. It's the recording that's correct, not the timer.
All of which is a long way of saying that the 'played X of Y' display is indicative, not an atomic clock! Yes, it will drift a little (and badly, after a pause), but it's there more as a visual cue and general progress indicator than as a pin-point accurate timer. So, you're observations are correct, but it's the nature of the beast, I'm afraid. Sorry!
Q. When I play music, the album art displays with a white bar and some illegible yellow text underneath it. What's wrong?
A. Definitely reproducible:
The problem is most likely that you've run out of usable disk space in /tmp, because Giocoso has to be able to write its analysis of the colours found in the album art to that file system. If /tmp is full, then it cannot write out the analysis, and thus ends up reading in blank for the discovered colours -and that means it makes the 'text panel' under the album art completely white... and goes on to select entirely the wrong text colour as well, just for good measure! Here's proof that the space problem in /tmp is an issue for me:
You can see I'm down to "0 avail" for /tmp, and 100% used. So: I cleaned out my /tmp folder (using the fairly crude technique of rm * issued as a non-root user whilst sitting inside the /tmp folder):
That's got me back to just 1% used, 99% or 7.8GB available for use, and my album art is back to its usual self:
The short version is, therefore, that Giocoso needs 'working space' in /tmp (not much of it, mind; but some) and bad things will happen if it can't get any at all.
[ Giocoso Manual Home ] | [ Installation ] | [ Troubleshooting ] | [ Changelog ] |