7hr track limit?

[Lester Hedges]

Hi there,

I have a few exceedingly long mp3 files (webcasts) that are 10 hours plus
in length. When playing them in cmus I've noticed that the player returns
to the beginning of the track when the running time exceeds 7 hours. This
happens both in normal playback mode and when using seek to skip to a point
beyond the 7 hour threshold, e.g. if I start the track and seek +8h I
actually go only 1 hour forward, seeking +9h goes 2 hours in. It looks like
the player is skipping to the current time modulo 7 hours. This seems to
happen with all long tracks that I've tried, regardless of the encoding.
All of the tracks play fine in other music players.

Is this a bug? Perhaps there's a track length limit hardcoded somewhere in
the source code (I haven't checked) or an accidental mod. For reference,
I'm running Arch Linux x64 using the latest version of cmus (2.5.0-2) from
the community repo.

Many thanks,
Lester

[Justin R]

Post by Lester Hedges
Hi there,
I have a few exceedingly long mp3 files (webcasts) that are 10 hours plus in
length. When playing them in cmus I've noticed that the player returns to
the beginning of the track when the running time exceeds 7 hours. This
happens both in normal playback mode and when using seek to skip to a point
beyond the 7 hour threshold, e.g. if I start the track and seek +8h I
actually go only 1 hour forward, seeking +9h goes 2 hours in. It looks like
the player is skipping to the current time modulo 7 hours. This seems to
happen with all long tracks that I've tried, regardless of the encoding. All
of the tracks play fine in other music players.
Is this a bug? Perhaps there's a track length limit hardcoded somewhere in
the source code (I haven't checked) or an accidental mod. For reference, I'm
running Arch Linux x64 using the latest version of cmus (2.5.0-2) from the
community repo.
Many thanks,
Lester

I used sox to generate an 11 hour triangle wave of middle A4 and
encoded to mp3 for testing this issue:
sox -r 8000 -c2 -n /opt/fast/test.mp3 synth tri 440 fade q 0.1 39600 0.1

(I'm a little concerned that file type and encoding may be involved,
but we'll continue for now.)

When loading it up in cmus for seeking it does not fail or loop around:
:seek +8h
:seek 0
:seek +10h

I notice that at further positions on a long track even short seeks
are very processor intensive and take much longer to complete. e.g.
:seek 0
:seek +5 is quick

:seek +8h
:seek +5 is now much slower

I'm not familiar at all with the cmus codebase, but I'm guessing
player_seek(double offset, int relative, int start_playing) is where
to start.

Could the track length be calculating incorrectly for your file?

[Lester Hedges]

Thanks, Justin. I followed your debugging instructions (using sox to
generate a long triangle wave) and can confirm that I see the correct
playback behaviour -- the track plays/seeks beyond 7hrs without jumping
back to the beginning.

The long tracks that I am experiencing problems with are encoded as MPEG
1.0 layer III, at either 96 or 128 kbits/s (found using mpg123). They are
from different sources so I'm not sure how they were originally encoded.
The track times are definitely correct since I can play the full length in
other media players (e.g. VLC works fine). I am also experiencing the same
problem using cmus v2.4.2 on OS X (from MacPorts) so it's not specific to
the Arch x64 build.

Cheers.

Post by Lester Hedges

Post by Lester Hedges
Hi there,
I have a few exceedingly long mp3 files (webcasts) that are 10 hours

plus in

Post by Lester Hedges
length. When playing them in cmus I've noticed that the player returns to
the beginning of the track when the running time exceeds 7 hours. This
happens both in normal playback mode and when using seek to skip to a

point

Post by Lester Hedges
beyond the 7 hour threshold, e.g. if I start the track and seek +8h I
actually go only 1 hour forward, seeking +9h goes 2 hours in. It looks

like

Post by Lester Hedges
the player is skipping to the current time modulo 7 hours. This seems to
happen with all long tracks that I've tried, regardless of the encoding.

All

Post by Lester Hedges
of the tracks play fine in other music players.
Is this a bug? Perhaps there's a track length limit hardcoded somewhere

in

Post by Lester Hedges
the source code (I haven't checked) or an accidental mod. For reference,

I'm

Post by Lester Hedges
running Arch Linux x64 using the latest version of cmus (2.5.0-2) from

the

Post by Lester Hedges
community repo.
Many thanks,
Lester

I used sox to generate an 11 hour triangle wave of middle A4 and
sox -r 8000 -c2 -n /opt/fast/test.mp3 synth tri 440 fade q 0.1 39600 0.1
(I'm a little concerned that file type and encoding may be involved,
but we'll continue for now.)
:seek +8h
:seek 0
:seek +10h
I notice that at further positions on a long track even short seeks
are very processor intensive and take much longer to complete. e.g.
:seek 0
:seek +5 is quick
:seek +8h
:seek +5 is now much slower
I'm not familiar at all with the cmus codebase, but I'm guessing
player_seek(double offset, int relative, int start_playing) is where
to start.
Could the track length be calculating incorrectly for your file?

[Gregory Petrosyan]

On Thu, Mar 14, 2013 at 8:07 AM, Lester Hedges

Post by Lester Hedges
I have a few exceedingly long mp3 files (webcasts) that are 10 hours plus in
length. When playing them in cmus I've noticed that the player returns to
the beginning of the track when the running time exceeds 7 hours. This
happens both in normal playback mode and when using seek to skip to a point
beyond the 7 hour threshold, e.g. if I start the track and seek +8h I
actually go only 1 hour forward, seeking +9h goes 2 hours in. It looks like
the player is skipping to the current time modulo 7 hours. This seems to
happen with all long tracks that I've tried, regardless of the encoding. All
of the tracks play fine in other music players.
Is this a bug? Perhaps there's a track length limit hardcoded somewhere in
the source code (I haven't checked) or an accidental mod. For reference, I'm
running Arch Linux x64 using the latest version of cmus (2.5.0-2) from the
community repo.

I've mirrored the issue to https://github.com/cmus/cmus/issues/29, so
that it won't be lost here.

Thanks a lot for the reporting — I'll try to look into it when I'll
have some free time.

Gregory