Re: emms-info-native and track duration

[Yoni Rabkin]

Petteri Hintsanen <petterih@iki.fi> writes:

> Yoni Rabkin <yoni@rabkins.net> writes:
>
>> After feeding the new code all of the track I could muster, the only
>> outliers are in a single album of ogg files which all return a 0 playing
>> time on all versions of info-native, new and old. Nothing immediately
>> stands out to me about the files in this album in terms of how the
>> header looks, but I haven't checked closely. In any case, it isn't a
>> regression.
>
> Great, thanks!
>
> Ogg Vorbis files are somewhat peculiar in the sense that the header does
> not contain the playing time, but one has to decode the very last ogg
> "page" from the file instead.  On that page there is a 'granule
> position' field, which contains the number of PCM samples in the stream
> up to that point.
>
> If you want to investigate further, you can evaluate
>
>   (emms-info-native-ogg--read-and-decode-last-page "filename.ogg")
>
> and see if it returns anything sensible, or just nil (in case of an
> error).  Also, does some external tool like emms-print-metadata,
> exiftool or ffprobe recognize duration?

OK, mystery solved. Except that it wasn't much of a mystery:

I took the time to simply call `emms-info-native-ogg-decode-metadata' on
the file and immediately got back that the comment size was too large
(102,951). That's what's happening behind the scenes. I needed to make a
different .emmsrc to check it (my maintainer-focused one is a mess, for
instance I had `emms-info-native--max-vorbis-comment-size' set in my
setup, which isn't `emms-info-native-vorbis--max-comment-size', so it
had no effect.) After running your code against a clean install, was
clear that reading the file was erroring out and therefore not updating
any element of metadata, not just the playing time. ...Of course that
when I ran code maphashed over all of the files, it returned a problem
with the playing time...

Perhaps it would be good to update the other pieces of metadata when the
comment is too long so that the user still gets the benefit of playing
time, title and etc.

It also makes me wonder if it makes sense to add a debug field to the
metadata when there is an error, and store error information in
there. That way it would be very easy indeed to figure out if any errors
occurred during reading just by looking for any tracks with a 'debug
symbol in their track alist. Just an idea.

-- 
   "Cut your own wood and it will warm you twice"