emms-help
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: emms-info-native and track duration


From: Petteri Hintsanen
Subject: Re: emms-info-native and track duration
Date: Mon, 23 Oct 2023 01:33:15 +0300
User-agent: Gnus/5.13 (Gnus v5.13)

Yoni Rabkin <yoni@rabkins.net> writes:

> 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.

This is doable.  Now the code is short-circuiting in the sense that
whenever there is an error processing a file, it just bails out for that
file.  It wouldn't need to be like that.  We could try to extract as
much usable data as possible.

As for the limits for comment field lengths etc, they are nowadays more
or less obsolete.  The rationale for limits was that bindat-unpack
function could hog excessive amounts of memory when reading data to
elisp vectors.  Now most of the variable length vectors have been
replaced by strings, which do not have that issue.  So almost all of the
limits could be removed, which I will do soon.  It is also the right
thing to do because e.g. many cover art metadata blocks can span
hundreds of kilobytes.  emms-info-native cannot yet extract them, but it
should not error (and consequently give up) either.

> 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.

This might be useful for debugging, perhaps via some defcustom, but I
wouldn't store that kind of information in regular use.  But the idea is
interesting, I'll keep it in my mind.

Thanks,
Petteri



reply via email to

[Prev in Thread] Current Thread [Next in Thread]