Re: emms-info-native and track duration

[Yoni Rabkin]

Petteri Hintsanen <petterih@iki.fi> writes:

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

Since it all seems to work well enough, perhaps it is time to merge it
into the main branch?

If you do, I'll postpone Emms 17 for a month or so to allow some more
testing and then release it as part of 17.

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