Experiencing something very weird since moving to Server 2.3 and client 2.2.
Any file exported out of Final Cut pro X (any FFMPEG readable codec) and placed into the media folder is read by Caspar CG as an Audio file and shows up in the audio section of your media list. However when placed in a rundown it has an audio icon but plays back the video and audio.
This does not happen when the same codec/ file is exported out of after effects.
Seems to be a metadata issue between FCPX and CCG. If you take the same file exported out of FCPX and re export it out of after effects, it is correctly ready by CCG and is placed in the videos section like it should be.
Usually what that means is that FCPX puts the audio on the first stream and the video on another stream, which is fine for playback but the media-scanner doesn’t understand that. There’s already a GitHub issue describing this: https://github.com/CasparCG/media-scanner/issues/40
I just did a fresh install of 2.3.3 server with 2.08 client on a newly built machine. I’m having this issue. @mint provided a link to the GitHub, but I’m not savvy enough to incorporate this fix. It looks like you need to adjust some lines of a scanner config file, but I can’t find scanner.js anywhere. Does anyone have a non-programmer’s guide on how to fix this issue?
A few months ago I managed to implement the patch to scanner version 1, the version included in the Github CCG server v2.3_LTS distribution. I have placed these updated files on Dropbox here
[Edit: Link updated to access without signing in to Dropbox, individual files can be accessed]
Download the four files. In the CasparCG server folder rename the existing leveldown.node and server.exe files (just in case…) and copy the downloaded versions of leveldown.node and scanner.exe into the server folder.
Database_Align.pdf describes a process to flush the existing databases in the server folder, and how to flush the client version 2.2 to make it re-load from the updated server database. Flushing a version 2.0.X client can probably be done from the client configuration Thumbnails Delete Now button, but I have not tested this.
I’ll try to leave the dropbox link open for at least a month, but it would be good if there were a widely known process that allowed the users to submit such patched files to a central repository so all the community had easy access to user created files.
I assumed there was no point in my adding a second pull request that duplicated an already submitted one. As best I can tell the pull request #41 was not included in the core system, and looking at the version 1.1 scanner.js the error of bad stream detection still has not been implemented in the core code.
@Julusian - Thank you for all your work sorting the scanner. I am pleased to report very fast return of all queries in both the server console and via direct connection to the http server in the scanner (using my Windows 10 based CasparCG testbed).
I have one issue remaining. I did a clean scan of my server media it returned all of the JPG and PNG still images as type AUDIO. I looked at the source code in line 221 of scanner.js which is:
if (stream.pix_fmt && stream.disposition?.default) {
Is the stream.disposition?.default test looking at some value returned by ffprobe? I have so far failed to locate detail in ffprobe help.
I made a local build of scanner 1.2 code base changing line 221 to a single test:
if (stream.pix_fmt) {
So far all of my tests show this correctly detects the correct media types for audio video and stills.
I think there are a couple of changes needed to version 1.2 readme.md. The build command changed slightly at version 1.1 but the readme was not updated. Looking at package.json the build commands have changed to include the target processor giving three build commands:
npm run build-win32-x64 npm run build-linux-x64 npm run build-linux-arm
I added the && stream.disposition?.default part, otherwise audio files with embedded artwork (mp3 music is a good test case) were detected as ‘VIDEO’.
I did not think to check it with any image files. I expect that either there is another disposition field which will indicate it is an image and we should treat it as an image, or maybe it should be blocking the stream based on a field instead.
This repository could really do with some unit tests to help ensure it is detecting correctly for various media. But that is more than I wanted to do as it would involve a fair amount of refactoring
Thanks for the hint about MP3 with cover art - I will find some examples of audio with album art to add to my tests.
I have been running tests on various file formats, extracting the JSON form as used by the call to ffprobe. Once I have time to collate the results I’ll post an update with the fields that may help identify a still that is only a still. It may require checking format.nb_streams which I have, so far, only seen to have the value 1 for a true still. All still formats I have so far checked have the stream.disposition.default set at 0. One item in the stream element that is looking of interest is stream[n].codec_time_base is the string “0/1”.
I’m still looking for further media samples for my tests. This note is an update on progress so far. The process I have manually tried involves scanning all streams in the json format data returned by ffprobe.
The stream type is identified by property streams[n].codec_type. This has two values of interest “audio” and “video”. A stream that contains a still image is identified by streams[n].codec_type === "video" and streams[n].codec_time_base === "0/1".
Before running the scan on all streams create an object similar to:
let st_types = {have_audio: 0, have_video: 0, have_still: 0}
If a stream identifies as audio, set st_types.have_audio = 4. Similarly for a video stream set st_types.have_video = 2, and for a still image stream set st_types.have_still = 1. These sum of the st_types is then used in a switch statement:
The 8 possible values and the media type interpretation is summarised in the following table :-
Audio
Video
Still
Total
CasparCG Type
0
0
0
0
AUDIO
0
0
1
1
STILL
0
2
0
2
MOVIE
0
2
1
3
MOVIE
4
0
0
4
AUDIO
4
0
1
5
AUDIO
4
2
0
6
MOVIE
4
2
1
7
MOVIE
Case 0 should not be needed as earlier tests in the calling function should catch this conditions. Case 4 is a pure audio file, such as a .WAV or .mp3 and case 5 is an audio track with a track thumbnail.
I created an updated function generateCinf(doc, json) in file scanner.js, and built a version of scanner 1.2.0.
The updated version of the scanner, built for windows only because I do not own a linux host system, is available at https://github.com/amwtech/casparcg-media-scanner. I allocated a version number of 1.2.0.1 to this copy.
The code for the media type detection function is below. This code may be slightly ‘clunky’, but so far correctly detects all media file types I have available for testing.
function generateCinf (doc, json) {
let tb = [0,1]
let dur = parseFloat(json.format.duration) || (1 / 24)
let type = ' AUDIO '
let streamTypes = {aud:0, vid:0, still:0}
let firstAudioStream = -1
let firstVideoStream = -1
for (let stream of json.streams) {
if (stream.codec_type === 'audio') {
streamTypes.aud = 4
if (firstAudioStream < 1) firstAudioStream = stream.index
} else if (stream.codec_type === 'video') {
if (stream.codec_time_base === '0/1') {
streamTypes.still = 1
} else {
streamTypes.vid = 2
if (firstVideoStream < 0) firstVideoStream = stream.index
}
}
}
switch (streamTypes.aud + streamTypes.vid + streamTypes.still) {
case 0:
case 4:
case 5:
type = ' AUDIO '
tb = (json.streams[firstAudioStream].time_base || '1/25').split('/')
break
case 1:
type = ' STILL '
tb = [0,1]
break
case 2:
case 3:
case 6:
case 7:
const fr = String(json.streams[firstVideoStream].avg_frame_rate || json.streams[firstVideoStream].r_frame_rate || '').split('/')
type = ' MOVIE '
if (fr.length ===2) {
tb = [fr[1], fr[0]]
}
break
}
return [
`"${getId(config.paths.media, doc.mediaPath)}"`,
type,
doc.mediaSize,
moment(doc.thumbTime).format('YYYYMMDDHHmmss'),
tb[0] === 0 ? 0 : Math.floor((dur * tb[1]) / tb[0]),
`${tb[0]}/${tb[1]}`
].join(' ') + '\r\n'
}
@rrebuffo - thanks for the alert about PNG scanning issues.
I know you are an experienced CasparCG builder and configurator, so I apologise for this simplistic question: “Did you delete the CasparCG server folders used for PouchDb - for example _media and _pouch_all_dbs_ before running the scanner?”. Once the type is allocated in an existing media scan the type is not changed by a subsequent run of scanner. Also note scanner version 1.2.x only uses a single folder for database storage _media
I did a small update a couple of days ago to the code in my version of scanner. The change should not have any effect on PNG files, but if you have time try the release 1.2.0.2 from my scanner version releases.
I have re-run all of my tests on the media samples I have, and all PNG files I have report as type STILL. I deliberately used files from different sources to avoid a single output library being used to write the files.
Can you share one of the PNG files that your system detects as AUDIO? I would obviously like to test on my Windows testbed. Alternately can you please run ffprobe on the file and share the output from ffprobe using a command line of the form:
All media type allocations work on the JSON data returned by probe, so if that probe data is not returning the items I check for determine a still file then scanner will make a default allocation to audio.
If the PNG file does also have an audio stream, typical of a track extracted from a CD or similar which has an album art or track art, this deliberately allocates as an audio file.
I did, yes!
I tested with both casparcg’s repo and yours and it came up as AUDIO. Reverted back to the version included in server 2.3 and it worked after clearing the database.
The PNGs were all wrongly identified, not one in particular. When I tried to look up a photo in the media explorer it was empty, that’s why I found this problem.
Now it seems to be working fine with your build, I’m not sure why it didn’t update the database the first time I tested it.