marcoc1712 wrote:
> That's strange, what about STDIN and enabled samplerates?
>
> In this case FLAC is the transcoder so target sample rate should be
> unique or STDIN is enabled, note that SOX will be engaged to resample to
> 88200 even if the input is the same (but it will not). If is not
Huey11 wrote:
> Checked stdin for flac and target rate to 88200 with source 88200.
> 28806
> Now get white noise?!
> Last executed:
> >
Code:
> >
> At: 2019/12/18 11:55:11
>
>
> Profile:
>
>
> flc-pcm-*-b8:27:eb:8c:8d:cc
>
>
>
> Command:
Huey11 wrote:
> Checked stdin for flac and target rate to 88200 with source 88200.
> 28806
> Now get white noise?!
> Last executed:
> >
Code:
> >
> At: 2019/12/18 11:55:11
>
>
> Profile:
>
>
> flc-pcm-*-b8:27:eb:8c:8d:cc
>
>
>
> Command:
paul- wrote:
> Audio::Scan was updated in most newer platforms to support OPUS file
> type. If you want to downgrade, you would have to build from sources
>
> https://github.com/Logitech/slimserver-vendor/tree/public/7.9/CPAN
>
> And then you would not be able to use the standard debian
marcoc1712 wrote:
> LMS in transcoding is annoying, I know, that's why C-3PO at beginning.
>
> BTW this error is from LMS, saying that no valid commands are executable
> for input flac, that meaning somehow transcoding has been disabled (in
> file types) or some executable (either FLAC or SOX)
Audio::Scan was updated in most newer platforms to support OPUS file
type. If you want to downgrade, you would have to build from sources
https://github.com/Logitech/slimserver-vendor/tree/public/7.9/CPAN
And then you would not be able to use the standard debian installer.
piCorePlayer a
Huey11 wrote:
> Ok, I think I give up. Looks like something else happens all the time.
> Now I see: >
Code:
> > [19-12-18 12:05:54.1808]
Slim::Player::TranscodingHelper::getConvertCommand2 (443) Error: Didn't find
any command matches for type: flc
I'm using the nightly from december 14.
http://downloads-origin.slimdevices.com/nightly/7.9/sc/0116432ea65227ec1453cb70cf0226019f325d29/logitechmediaserver_7.9.2~1576322676_arm.deb
Before that I used the nightly from june and I changed to the more
recent one in the hope that the CLI got fixed.
I used Microsoft Edge. With Chrome I managed to login :)
Ok, good to know!
But now I have trouble finding "Settings".
It's the settings in LMS: Settings/Advanced/Spotty/Spotify Client ID
--
Michael
___
Squeezecenter mailing list
Ok next problem, sorry: any idea why I might have a small hickup when
starting the stream? It starts, stops for a short moment then resumes. I
am thinking some buffer?
Regards,
Huey11's Profile:
Huey11 wrote:
> Ok next problem, sorry: any idea why I might have a small hickup when
> starting the stream? It starts, stops for a short moment then resumes. I
> am thinking some buffer?
>
> Regards,
It happen only with the first track of a playlist (or album) or also
when switching from
marcoc1712 wrote:
> I'm currently using Debian on x64 with Audio:Scan 0.9.5:
>
> 28809
>
> I understand your point and feel free to fork C-3PO and produce a patch
> or distribute it for ARM, I could not do that at the moment, sorry.
Ok, no prob. I understand your time is limited. Especially
Hi,
I hope someone can help me out. Lately I have some problems with playing
hires (>24bit 96khz) files on my main system. I thought it was player
hardware related but it is also not working in the kitchen with my SB
Touch. There is no sound. Looking at the server log I see a lot of these
paul- wrote:
> Audio::Scan was updated in most newer platforms to support OPUS file
> type. If you want to downgrade, you would have to build from sources
>
> https://github.com/Logitech/slimserver-vendor/tree/public/7.9/CPAN
>
> And then you would not be able to use the standard debian
Thanks. I just like to show you a telnet session to illustrate what is
working and what is not working
b8:27:eb:d0:cc:13 playlist resume 44-21-65-188-196
b8%3A27%3Aeb%3Ad0%3Acc%3A13 playlist resume
%2Fsrv%2Fmusic%2FPlaylists%2F44-21-65-188-196.m3u
b8:27:eb:d0:cc:13 playlist name ?
Debian Buster uses perl 5.28, which all architectures for perl 5.28 are
using Audio::Scan 1.02.Going backwards and building just takes time,
and users helping to build binaries for LMS. Michael gladly accepts
pull requests.
piCorePlayer a small player for the Raspberry Pi in RAM.
marcoc1712 wrote:
> It happen only with the first track of a playlist (or album) or also
> when switching from track n to n+1?
>
> If 2, it's probably the alsa buffer size/count of squeezelite or maybe
> also the input/output buffer size (-b).
>
> If 1, could be different causes. Try
marcoc1712 wrote:
> Just becouse it could be different in output and I'm looked to the one
> coming from 0.9.5, since the standard distributed was 0.9.2, back in
> 2012... I could change, obviously, but in that case I'll probably go for
> soxI-
>
> Sorry but I have no time and no BananaPI to
Huey11 wrote:
> It is not a bananapi thing: it is debian on arm, but also on x86 I
> think, so basically the linux for most sbc's, raspberry pi's but also
> the odroid's etc?
I'm currently using Debian on x64 with Audio:Scan 0.9.5:
28809
I understand your point and feel free to fork C-3PO
paul- wrote:
> Debian Buster uses perl 5.28, which all architectures for perl 5.28 are
> using Audio::Scan 1.02.Going backwards and building just takes time,
> and users helping to build binaries for LMS. Michael gladly accepts
> pull requests.
>
>
> Why do you need to distribute Scan.pm
paul- wrote:
> Debian Buster uses perl 5.28, which all architectures for perl 5.28 are
> using Audio::Scan 1.02.Going backwards and building just takes time,
> and users helping to build binaries for LMS. Michael gladly accepts
> pull requests.
>
>
> Why do you need to distribute Scan.pm
Bungle68 wrote:
> Whats a cue file?
> The majority of these, simply have the album folder name, with the
> tracks inside, some do however, have the folder, with CD1 and CD2 with
> the tracks in those, do you think that may be the issue?
> What would be the simplest way to resolve this, edit
Bungle68 wrote:
> Hi
> Im a total newbie with a really annoying issue :mad:. I have copied
> around 100 albums, so far onto a SSD which is linked to a Raspberry Pi
> running Max2Play, so i can connect to a Squeezebox Radio i have bought
> for y daughter xmas prezzie. When i do a scan to load
Hi
Im a total newbie with a really annoying issue :mad:. I have copied
around 100 albums, so far onto a SSD which is linked to a Raspberry Pi
running Max2Play, so i can connect to a Squeezebox Radio i have bought
for y daughter xmas prezzie. When i do a scan to load the library, i get
the albums
Whats a cue file?
The majority of these, simply have the album folder name, with the
tracks inside, some do however, have the folder, with CD1 and CD2 with
the tracks in thise, do you think that may be the issue?
You could pick 2 of the duplicate tracks in the LMS web interface and
click on "M" (for more) and see what it shows for the track info.
It should give a clue about where they came from.
e.g. is there a backup of the music folder somewhere?
Paul Webster
http://dabdig.blogspot.com
Author Radio
Some one else noted this, but having both ID3v1 and v2 can be a problem
if for some reason they get out of sync. LMS will read v1 first (if it
is there) but most taggers might only show v2 unless v2 is removed.
I've had to really dig in at times.
A problem I've also had is capitalization.
slartibartfast wrote:
> Of course it was. He wants an easy to set up low power system and both
> Max2Play and pCP fit the bill.
I'm not the OP, but the answer helped me, because I want to use MusicIP.
I'm going to give Max2Play a go.
Something else I've posted about in the past, is that LMS respects
leading and trailing spaces. So if u have any, in say the album artist
field, disc field, etc, could be the issue, assuming the behavior is the
same.
Also, I don't merge multidisc sets, bc I want to see one artwork per
physical
29 matches
Mail list logo
