philippe_44 wrote:
> My observation on the Smokey Robinson file was an error toward the
> *very* end (confirmed by both ffmpeg and my built-in decoder)
Log from ffmpeg of Smokey Robinson track - shows the error in input
stream - not a duration issue or EOF error.
Code:
benh wrote:
> By amazing coincidence, that error above is from 1-13_Last_Kiss.m4a.
> The error plus the bit immediately after, when the session ends:
>
> [alac @ 0x56149523bc40] invalid samples per frame: 0/s speed=80.7x
> Error while decoding stream #0:0: Invalid data found when processing
>
benh wrote:
> I understand what you are saying, and your example is helpful.
>
> I think perhaps I have been misunderstanding the nature of this
> particular encoding error. I had understood it to be an error in
> encoding some audio at an arbitrary and random timecode. What I now
>
bpa wrote:
> I checked out the container structure of the 1-13_Last_Kiss.m4a file and
> it was OK.
>
> Which is the file that ffmpeg throws up an error ? I'll check it out.
> The issue might be something like metadata which can be Apple
> proprietary.
This one has en error
By amazing coincidence, that error above is from 1-13_Last_Kiss.m4a.
The error plus the bit immediately after, when the session ends:
[alac @ 0x56149523bc40] invalid samples per frame: 0/s speed=80.7x
Error while decoding stream #0:0: Invalid data found when processing
input
size=5876kB
benh wrote:
> This suggests to me that the payload of the misencoded file is intact
> and that the error is in a container structure.
I checked out the container structure of the 1-13_Last_Kiss.m4a file and
it was OK.
Which is the file that ffmpeg throws up an error ? I'll check it out.
I understand what you are saying, and your example is helpful.
I think perhaps I have been misunderstanding the nature of this
particular encoding error. I had understood it to be an error in
encoding some audio at an arbitrary and random timecode. What I now
speculate may be happening is
ThatÂ’s the situation I explained above. Try decode error happens when
the output buffer is still full of unheard audio because decoding
happens way in advance.
For standalone players, when LMS receives the decode error notification,
it let the player go to the end of whatever it has in its
philippe_44 wrote:
> - 10 seconds is likely related to the size of the output buffer. The
> error happens at the very last *decoded* bytes and you have always ~10s
> un-played audio in the buffer, likely - that explains regularity
>
> - faad is always implicated when you use a SB3 in the mix
benh wrote:
> I'm also not sure there's not a bug in the Group Player and
> Synchronization code. I just went to play some stuff, and found my
> Bedroom player synched with "Upstairs" which is a Group Player
> consisting of Bedroom and Library. I definitively did not do that.
I've seen some
benh wrote:
> I really appreciate your efforts to figure this out.
>
> I'm completely willing to believe that a single file is incorrectly
> encoded. I am less certain that random files are incorrectly encoded,
> and that they are all incorrectly encoded such that the problem occurs
> at the
I'm also not sure there's not a bug in the Group Player and
Synchronization code. I just went to play some stuff, and found my
Bedroom player synched with "Upstairs" which is a Group Player
consisting of Bedroom and Library. I definitively did not do that.
I really appreciate your efforts to figure this out.
I'm completely willing to believe that a single file is incorrectly
encoded. I am less certain that random files are incorrectly encoded,
and that they are all incorrectly encoded such that the problem occurs
at the exact same point in their
benh wrote:
> So here is something interesting. I have found a combination of players
> that don't work AT ALL.
>
> I went through and created various group players in various combinations
> to see if there was a common player factor.
>
> Two pCP/SL: 10 Second issue
> SB Radio and BOTH
And just to prove this isn't a Motown problem, here's a pop track with
the same issue. https://filebin.net/kvjhkgkx3x6yl0dt
benh's Profile: http://forums.slimdevices.com/member.php?userid=6732
View this thread:
philippe_44 wrote:
> So back to square one. Player dc:a6:32:f9:a1:eb is unhappy with the
> format of what it receives toward the end. What player is that? Can you
> reconfirm it works normally when played standalone? Can you also upload
> the file creating problem on filebin (or any other
benh wrote:
> OK. I set the plugin.groups logging to debug, deleted that group
> player, and created a new one, appending a 2 to the name.
>
> The file played (yay!), but stopped 10 seconds before the end. So now
> this group acts like the others.
>
> I literally created the original group
OK. I set the plugin.groups logging to debug, deleted that group
player, and created a new one, appending a 2 to the name.
The file played (yay!), but stopped 10 seconds before the end. So now
this group acts like the others.
I literally created the original group as part of my testing, so I
But... comparing logs and refreshing my memory on my own code, I'm
pretty sure that the issue is that your Group player (the virtual
player) is not using a special StreamingController, so the group is not
build on "play" request. It should never happen unless the group has
been "damaged" for
So last thing, can you put the Group player log to debug and take the
same log again so that I can see why the group is not assembled *before*
checking for common codecs?
LMS 8.2 on Odroid-C4 - *SqueezeAMP!*, 5xRadio, 5xBoom, 2xDuet, 1xTouch,
1xSB3. Sonos PLAY:3, PLAY:5, Marantz NR1603,
benh wrote:
> Nothing illuminating, I'm afraid. This is, to confirm, an attempt to
> play that track to the Radio/Library group that just doesn't play at
> all.
>
> >
Code:
> > [21-04-23 16:13:17.5988] Slim::Player::StreamingController::play (2120)
02:00:96:66:70:5e
Nothing illuminating, I'm afraid. This is, to confirm, an attempt to
play that track to the Radio/Library group that just doesn't play at
all.
Code:
[21-04-23 16:13:17.5988] Slim::Player::StreamingController::play (2120)
02:00:96:66:70:5e
[21-04-23 16:13:17.5997]
philippe_44 wrote:
> Right, so this is the insanity: it means that the players are saying
> that they do not support any common format. When LMS does a sync group,
> it builds a list of supported codecs by retaining the overlapping ones
> from all players and feeds that to the transcoder to
benh wrote:
> Log with Data :: Dumper added, and debug for player.source enabled.
>
> >
Code:
> >
> [21-04-23 14:25:01.4179] Slim::Player::StreamingController::_Stream (1210)
Song queue is now 0
> [21-04-23 14:25:01.4180]
Code:
[21-04-23 14:24:14.2140] Plugins::ShairTunes2W::Plugin::publishPlayer (440)
avahi-publish-player not in path
[21-04-23 14:24:14.2140] Plugins::ShairTunes2W::Plugin::publishPlayer (449)
dns-sd not in path
[21-04-23 14:24:14.2141]
benh wrote:
> Here is convert.conf from the Docker container. I named it
> convert.conf.docker for clarity.
>
> I do not have a custom-convert.conf that I'm aware of, with the
> exception of these:
>
> % find ./ -name custom-convert.conf -print
>
philippe_44 wrote:
> Would mind attaching your convert.conf and custom-convert.conf?
Here is convert.conf from the Docker container. I named it
convert.conf.docker for clarity.
I do not have a custom-convert.conf that I'm aware of, with the
exception of these:
% find ./ -name
philippe_44 wrote:
> BTW, on this combination
>
> Does it fail as well if the players are statically synchronized?
When the players are statically synchronized, the track plays and then
stops at 10 seconds before the end.
BTW, on this combination
benh wrote:
> So here is something interesting. I have found a combination of players
> that don't work AT ALL.
> SB Radio and Library pCP/SL: Track won't even start playing. Here's the
> debug from that:
>
Does it fail as well if the players are statically
OK, here's that log. This worked, in that the song played through to
completion.
I don't seem to have a convert.conf or custom-convert.conf anywhere in
the normally-accessible portion of my Docker setup, so I'll have to
export it from the Docker image. Be a bit for that.
benh wrote:
> To clarify, do you want a log from a play attempt from JUST the pCP that
> is a problem, or from a group containing the Radio and that pCP? The
> above log is the latter.
The former, I'd like to see what JUST that pCP does. Would mind
attaching your convert.conf and
philippe_44 wrote:
> Can you take that log but just with the pCP that causes the issue when
> synced with the SB radio? (the case were it does not play at all). I'm
> baffled by the fact that LMS says that it can't find a transcoding rule
> for an mp4 *file*, and knowing that you're using
benh wrote:
> I agree that it should. I can say definitively that player.source is in
> debug. If there are other modules I should set debug on, happy to do
> so. These logs are coming from the web UI, from
> /config/logs/server.log.
Can you take that log but just with the pCP that causes
philippe_44 wrote:
> But still, log in debug should contain more. Are you sure it was the
> full log and debug?
I agree that it should. I can say definitively that player.source is in
debug. If there are other modules I should set debug on, happy to do
so. These logs are coming from the web
bpa wrote:
> What you thought was "relevant".
> Sometime what is missing is more important - and only context can show
> what is missing.
You got it. Here is a more complete snippet of that log, with several
lines of previous state and future state included. This is everything
that was
benh wrote:
> Nope, those are bone stock, as far as I can recall.
But still, log in debug should contain more. Are you sure it was the
full log and debug?
LMS 8.2 on Odroid-C4 - *SqueezeAMP!*, 5xRadio, 5xBoom, 2xDuet, 1xTouch,
1xSB3. Sonos PLAY:3, PLAY:5, Marantz NR1603, Foobar2000,
philippe_44 wrote:
> This is interesting & strange ... can you put that loglevel to debug. It
> will be verbose but will give a better idea of what the rule matcher is
> trying to do
>
> [edit]: sorry, I saw it's debug now but I was expecting to see more. Do
> you have a modified convert.conf
benh wrote:
> Well, it is short. That is because I only cut and pasted the contiguous
> section of log that was relevant to this transaction. Player pretty
> much goes from idle to nope to idle.
What you thought was "relevant".
Sometime what is missing is more important - and only context
benh wrote:
> LMS MPEG4 Settings are:
>
> >
Code:
> > MPEG-4
>
> AAC (I, F) Native
> FLAC(F) faad/flac
> MP3 (F) faad/lame
> PCM (F) faad
> >
>
>
> Well, it is short. That is because I only cut and pasted the
bpa wrote:
> This log looks very short. Lines look missing. Did you enable
> player.source to INFO ?
>
> What are the LMS MPEG4 settings in WebUI Settings/Advanced/Filetype
LMS MPEG4 Settings are:
Code:
MPEG-4
AAC (I, F) Native
FLAC (F)
benh wrote:
> SB Radio and Library pCP/SL: Track won't even start playing. Here's the
> debug from that:
>
> >
Code:
> > [21-04-23 11:08:45.4894] Slim::Player::StreamingController::_Stream
(1213) 02:00:96:66:70:5e: preparing to stream song index 0
> [21-04-23
So here is something interesting. I have found a combination of players
that don't work AT ALL.
I went through and created various group players in various combinations
to see if there was a common player factor.
Two pCP/SL: 10 Second issue
SB Radio and BOTH pCP/SL: 10 Second issue
SB3 and
philippe_44 wrote:
> If it happens only with groups, have you checked all individual players
> with the same file one by one? Are they all the exact same squeezelite
> version? Other than that, can you upload somewhere one problematic file?
It happens with synchronized players as well as
If it happens only with groups, have you checked all individual players
with the same file one by one? Are they all the exact same squeezelite
version? Other than that, can you upload somewhere one problematic file?
LMS 8.2 on Odroid-C4 - *SqueezeAMP!*, 5xRadio, 5xBoom, 2xDuet, 1xTouch,
I don't think faad is running/being called. I didn't see it running at
any point during playing of this file.
Here's what faad says:
Code:
root@2cc3948a001f:/lms/Bin/x86_64-linux# ./faad
*** Ahead Software MPEG-4 AAC Decoder V2.7 **
benh wrote:
> I mean to say that the ALAC files that are all problematic were all
> originally FLAC, transcoded to ALAC and then included in my LMS library.
> I use iTunes to manage my library, so all of my lossless music is ALAC.
> And indeed, I have a LOT of ALAC files that were transcoded
>
> For the ALAC files, they are transcodes from flac, and are tracks in
> different albums by different artists from different sources. On one
> album, other tracks exhibit the same issue in a grouped player or set of
> synchronized players, but not to a singular player. On another, it's
>
benh wrote:
> I ran that command on the AAC/M4A file:
>
> >
Code:
> > Stream mapping:
> Stream #0:0 -> #0:0 (copy)
> Press [q] to stop, [?] for help
> [mov,mp4,m4a,3gp,3g2,mj2 @ 0x55ea023e6980] Packet corrupt (stream = 0, dts
= 7911424).
> 01 The Tears Of A
bpa wrote:
> If you are messing with the file. You should check whether the file
> FASTSTART enabled (i.e. streamable) is an issue.
>
> A file is "streamable" when the index to audio frames is placed at start
> of the file (i.e Flag FASTSTART is enabled when file is created).
>
> The
benh wrote:
> I may try to re-transcode a file from the source flac to alac again and
> see what happens.
If you are messing with the file. You should check whether the file
FASTSTART enabled (i.e. streamable) is an issue.
A file is "streamable" when the index to audio frames is placed at
bpa wrote:
> This error is often (not exclusively) shown when LMS tries to stream an
> "unstreamable" MPEG-4/AAC source for native decoder.
> Phillippe would be best placed to answer the questions but more
> information will help.
>
> 1. Are all the players identical ? are they all all
benh wrote:
>
> [21-04-18 22:54:21.6627] Slim::Player::Squeezebox2::statHandler (149)
> Error: : Decoder does not
> support file format, code 0
>
> I have confirmed that these files play normally using other music
> players, such as iTunes. I can play the SAME file on a single pCP
> rather
This also happens if I synchronize players the normal way, it turns out.
So it's probably not a group players problem.
benh's Profile: http://forums.slimdevices.com/member.php?userid=6732
View this thread:
I have begun to have (or just noticed I have) a problem with Group
Players. Some songs stop playing prematurely, seemingly exactly 10
seconds early, and display an error on the player screen:
Problem: Can't open file for:
And the following error is logged in LMS:
[21-04-18 22:54:21.6627]
54 matches
Mail list logo
