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 issue (see below for the eventual fix, however!). 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 truncation errors: if a track lasts 3 minutes 27.51 seconds, Giocoso will calculate it to be 3 minutes 28 seconds long. Up to 0.99 seconds of a track's duration can thus be lost by truncation: if you have multiple tracks making up a recording, that extra 0.99 seconds per track can start adding up to a claimed duration for the whole recording that's significantly longer than it truly is. Truncation can also produce timing errors the other way, of course.
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!
Updated for Version 3.20 and above: Everything written above is now no longer true in Giocoso Version 3.20 and above!! That version introduced the ability of Giocoso to directly read the music-playing engine's location within the music stream, in near-realtime. This means that in the 'Played X of Y' display, the 'X' is always accurately and precisely known. The 'Y' is easy to detect directly, too (it's just the duration of the recording being played, which is trivially obtainable). Hence, all parts of the 'X of Y' display are always accurate (sort of... see below). The 'Ending at' computation is thus pretty accurate now, too. If I know you've played 5 minutes out of 20 and the current clock-time on your system is 10AM, I know this recording will end at 10:15. If at 10:10 you pause playback, you are now 15 minutes into the recording, with five minutes to go: as you initiate a pause of playback, the 'X' component will stop incrementing (obviously, because you've stopped playing music!) and the 'Ending at' time will begin to increment, one second for every one second of pause. The 'Ending at' time gets pushed back, in other words, for as long as the pause continues. If you come back at 10:30 and re-initiate play, I know you've still got 5 minutes of the recording to play, so I can update the 'Ending at' time to be 10:35: that then stays fixed, and the 'X' component will resume incrementing once more.
The times displayed in this part of Giocoso's program output are now all accurate, from Version 3.20 up. Only two sources of imprecision remain: 1) your system clock does not keep perfect time, so if it drifts at all, then Giocoso's clock calculations will be 'off'; and 2) Giocoso still truncates times to whole seconds, whereas the underlying music playback engine reports its progress down to centiseconds. That is, if X really ought to be 'you've played 00:05:33.34 seconds of this recording', Giocoso will truncate the digits after the decimal point and report (and calculate) based on you having played 00:05:33 of it. The truncated tenths and hundredths of a second can add up for a long recording and introduce a second or so of inaccuracy. Giocoso will actually correct for this if accumulated drift from clock-time exceeds 2 seconds. Otherwise, a 2-second inaccuracy is something you still have to live with.
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.
Q. When I start playing music, using my local PC to control a remote ssh session, the display gets a bit garbled with blank space displaying where it shouldn't. What's up?
Reproducible. You are probably describing this sort of output:
That break in the line-drawing characters to the right of the 'Ending at', which appears to obliterate the first part of the next line, again leaving a blank space which shouldn't be there, is probably what you're looking at. The trick is to highlight that area of the screen and copy-and-paste the text into, say, a text editor of your choice ...and then you'd see the text which is actually causing that 'blank space':
Pulling that text out completely, you'd see it says: connect /tmp/.X11-unix/X1: No such file or directory. That's a fairly common ssh error and nothing technically to do with Giocoso: it's just that Giocoso doesn't know how to handle ssh-related errors gracefully.
There are numerous online resources for solving this issue: see, for example, this one. In a nutshell, it means that something is wrong with your ability to do X-forwarding and that the remote PC running Giocoso doesn't know how to write back to the screen display your local PC is running. Commonly, that's because the DISPLAY environment variable is set incorrectly. It can also be because your local PC has its own ssh server configuration which is messed up in some way. This recently happened to me, for example: I had actually just installed ssh server for the first time onto my local PC and this screwed up the remote PC's ability to draw to my X server (display): a simple reboot resolved that particular issue. If a system update and a reboot (of your local PC) doesn't resolve the issue, then you will need to brush up on your Google-fu and try and diagnose your ssh/X forwarding issues using whatever online resources you can find. It fundamentally isn't Giocoso going wrong, though.
[ Giocoso Manual Home ] | [ Installation ] | [ Troubleshooting ] | [ Changelog ] |