[Stills] No still job on audio files

[Frans]

We see that still jobs are started regardless of the type of media. Still jobs should not be started with audio files

server	Einde STILL job: 512433 met status: FAILED
Go to asset 1S6QQ41jTsxF8B2ljBC5XXYv

[forgacs]

@Robert: I have implemented a check on mime type in the create_still_job() function. If the current file is audio, then it doesn't start the still job.
It doesn't drop any exception in case of audio file, but we can consider this behavior.

[forgacs]

@Robert: I have implemented the new exception. It catch (and hide) the exception in case of upload.

[Michiel.Schok]

Uploaded audio mediafile.
Asset 'E1ggfsYtfUGQmSETQynw1mBY' / mediafile 'q1eHbkjXsOnGfTDBKHzpSeVO' .
Details available at  http://beheer.acceptatie.vpcore.snkn.nl//admin/mediamosa/browse/asset/E1ggfsYtfUGQmSETQynw1mBY

My observation:
1. 3 jobs are started: id 2189 (upload), 2190 (still), 2191 (transcode)
2. job 2190 and 2191 failed, and *both* show up in logging.
3. The only message that is missing in the logging is 'job 2190 failed'.

Me thinks (but Frans can override me of course) that this is a crappy workaround and a waste of time.

I would have liked to see that somewhere in the process of sending a job to the queue or picking it up and starting to run ffmpeg that there would be an analysis of the technical metadata of the mediafile. And if MediaMosa detects that it is an audio-file, then there should be a graceful exit. Not a FAILED code, but rather 'INFORMATION': still job not executed on an audio-only file.

On the other hand: at the moment, there is so much logging into the page  http://beheer.acceptatie.vpcore.snkn.nl/admin/mediamosa/browse/log that I don't use it anymore for troubleshooting or informational purposes to keep an eye on potential problems.

so, therefore: tested: yes, accepted: to decide by Frans.
Will add some screenshots.

[Frans]

Not accepted.

"I have implemented a check on mime type in the create_still_job() function. If the current file is audio, then it doesn't start the still job."

Needs attention ans will reopen.

[Michiel.Schok]

I was triggered by the 'mime type' in the note of Frans.
Closer inspection reveals the mime-type to be 'application/octet-stream'...
Strange for a mp3 file, but that's another problem.

But I tried a couple of more files, and finally found a file with mimetype 'mpeg/audio'. And then, no still job is generated, and we observe another entry in the log file, which is attached as screenshot.

and then it seems that it has been implemented as I would have liked...
I stand corrected.

[Frans]

So the real issue here is that mp3 should be tagged with an other Mime type than application/octet-stream.

One of:
audio/mpeg, audio/x-mpeg, audio/mp3, audio/x-mp3, audio/mpeg3, audio/x-mpeg3, audio/mpg, audio/x-mpg, audio/x-mpegaudio

[forgacs]

@Robert:
It should work well, if the mime type is one of the "audio/...".
I think the problem is the "application/octet-stream".

[Michiel.Schok]

Correct, I tried some .mp3 files, and the one that detected as 'audio/...' went well.
As we rely on the 'file' tool to produce correct mime-types, this ticket can be closed.