Hi there ! I did a from scratch Libretime 3 alpha 4 install on Debian stretch, by using previous Airtime 2.5 database (via pg_restore) ; everything works fine, all previous data have been correctly reinjected, I’ve got all my calendar, users, stream settings etc. from the previous airtime 2.5, and the available tracks appear as well (and they all have been rsynced to the new server - no path changing ) BUT, when I schedule them, they play blank ; progress bar is progressing like it has to do ; same problem when I try to monitor/preview them, nothing plays (but metadata display in the monitor player). Liquidsoap log says :
2018/09/20 12:24:22 [dummy(dot)3:3] Source failed (no more tracks) stopping output…
2018/09/20 12:24:22 [dummy(dot)4:3] Source failed (no more tracks) stopping output…
On the other side, freshly uploaded tracks (post install) plays without problems in schedules, and the monitor/preview works fine also. the problem ONLY concerns tracks already present in the databse before Libretime install ; the stor path has been set to match already existing tracks. New uploaded tracks are stored in the same ‘imported’ path, nearby the old restored tracks. Those old track work perfectly in liquidsoap when falling back to fallback playlist (usual tweak for Airtime to have a 24/24 playlist when airtime is offline) with a .m3u paths file. Any idea ?
Hmm, this is odd, what you describe should work in theory, but lets try and figure it out.
First I’d check the permissions of the files that were imported and see if they are identical to the ones uploaded, perhaps www-data can’t read them.
Another thing to check would be the database - see the cc_files entries for your previous tracks and how they compare to the existing tracks “look” in the database vs. the new ones. Is there a difference perhaps in how the path is coded or something else that might make a difference in playback.
Also is there anything in the pypo log, or the zend-php.log.
I ran into something similar when I was trying to import existing files into the filesystem without moving them to implement the watched folder feature, and I couldn’t preview or playback the tracks. I didn’t dig deep enough to figure it out because the code I had to write to get this to work was kind of convoluted. So if we can figure out the cause of your issue it might help if someone wants to develop this feature as well.
Hi, thanks for your answer ! I checked the filepath in the database (filepath on cc_files table), and I just saw one différence :
Example :
post install imported file -> imported/1/Harpsicorpse/vZRK 11 - Suite for the harpsichord/B6 Harpsicorpse - Outro.mp3 #works without problem in scheduler and in preview/monitor player
from previous airtime 2.5 install imported -> imported/1/Quantic Presenta Flowering Inferno/Dog with a rope/3-Swing easy-320kbps.mp3 #doesn’t work, except via the m3u fallback
The only différence I notice is that airtime rewrites the filename by ending it with the track bitrate, Libretime does not ; I don’t think this is the problem, so are the track file named, so they appear in the database.
I also noticed that both, post install & previous imports tracks, appear in the /var/tmp/airtime/pypo/cache/scheduler folder, but the old ones have 0 bytes data ; obviously problem seems to come from here, cached files are empty files for the previous imported tracks
Hmm, so I would suspect a permission problem, ie the pypo process isn’t able to copy the old tracks for some reason, or something happened to the files and they are empty, so it is copying the empty files. This is a possible explanation for what is happening. I would check the permissions of the old tracks and see if they have the same exact permissions as the tracks that are uploaded.
There is no permissions problem (0 bytes files wouldn’t be written), but i think i found what goes wrong. The previous airtime db didn’t contain the cc_files.filesize column, created at libretime’s installation, so all the tracks imported from the previous db have this column’s value set at 0 while the post install uploaded tracks have their value set as an integer = file size in bytes, that’s probably why those 0 bytes tracks exist in the scheduler cache…I’ll soon trying to script something to fill those cc_files.filesize columns with the files size from the stored files…and i’ll let you know Cheers
Awesome, this is good to hear. If you want to share your script it might be useful if anyone else runs into a similar situation while manually importing.
Cheers