@barefoot wrote:
@magnate wrote:
What is in your lastfmsubmitd logs? (/var/log/lastfm/*)
What versions are you running (of mt-daapd, of python, etc.)?
What distro are you using?I wonder if we are using slightly different versions of lastfmsubmitd – I’m using the one packaged for Debian, which I think has been slightly tweaked from the original.
Sorry I don’t have any better ideas at the moment, but happy to try and help.
Thanks for the help. Actually, I was successful in working around the problem yesterday, even if I don’t know the exact reason for failure. What I now do is: At the end of the script, I sleep for 5 second and then collect all files in the spool directory (if still existent) to one single file in a separate place and copy it back to the spool directory. This file is recognized reliably (and if not, it is collected next time), all the others get erased. I don’t know why it works, but it does.
lastfmsubmitd recognizes the files it does not scrobble (if I erase them, it complains that they vanished and crashes). Maybe it works too fast and begins scanning the files before they are completely written – but then my workaroung should also fail. No clue.
I use lastfmsubmitd from sources on a slow MIPS architecture with SLUG binaries. python is actually 2.4, maybe should I upgrade to 2.5?
Well, according to Debian, lastfmsubmitd is agnostic about which version of python you have, so it shouldn’t be necessary – but it can’t do any harm to upgrade. If you wanted to look into lastfmsubmitd itself (it’s actually only a couple hundred lines of python code), you could probably find where it’s waiting for files to appear in the spool dir, and lengthen the wait from every few seconds to every minute or so – that should solve the slow writing problem, if that’s the cause of the failure.
I remembered one other thing yesterday – the awk invocation in the script uses the strftime feature which is in gawk but not in mawk. I thought that might have been the problem, if you were running mawk, but it would have had a completely different solution from the one you found. Oh well. Well done on sorting it out,
CC