Ummm, sure, a lot of us here have built such systems.
If you want to sync all 10 players together in one group youd need
players with very good timing or youll see dropouts but 3-4 per group
should also work with a RPi.
You should not run a player on the RPi that runs the server, it will lag
reinholdk wrote:
> My workaround is: I've built two scripts that I'm calling from mp3tag's
> context menu. One for saving the current timestamp, one for incrementing
> the saved timestamp by a second and applying it.
I assumed that was possible, but never tried it. I have to wipe the
cache and
Thank You digimaster for quick response.
This is what I get from ./QLogitechMediaServer.sh restart:
26802
26801
+---+
|Filename: Bildschirmfoto 2019-02-20 um 13.10.18.png|
|Download:
dolodobendan wrote:
> Not there yet.
>
> >
Code:
> >
> [13:10:25 20-02-2019] LogitechMediaServer 2.03.31 is installed !
> [13:12:39 20-02-2019] Upgrading LogitechMediaServer to 7.9.2-1550612824,
please wait !
> [13:12:59 20-02-2019] LMS will start with:
I should know this but don't. Using the web interface, how do I switch
a player to another library on another server (different machine within
my network)? I generally do this with iPeng, but can't figure out how
to do this with LMS directly.
john greenwood wrote:
> I should know this but don't. Using the web interface, how do I switch
> a player to another library on another server (different machine within
> my network)? I generally do this with iPeng, but can't figure out how
> to do this with LMS directly.
LMS left panel >
slartibartfast wrote:
> I am having the same issue with Flaming Lips podcasts. Every 5 minutes
> playback stops and I need to restart playback from the beginning
> skipping to the required position. The feed is
> http://podcast.rhinofy.com/theflaminglips/feed.xml
This is the server log with
dolodobendan wrote:
> Yes, I meant within mp3tag.
My workaround is: I've built two scripts that I'm calling from mp3tag's
context menu. One for saving the current timestamp, one for incrementing
the saved timestamp by a second and applying it.
digimaster wrote:
> Should be fixed with 2.03.31.[emoji848]
Not there yet.
Code:
[13:10:25 20-02-2019] LogitechMediaServer 2.03.31 is installed !
[13:12:39 20-02-2019] Upgrading LogitechMediaServer to 7.9.2-1550612824,
please wait !
[13:12:59 20-02-2019] LMS
digimaster wrote:
> Oké the. CHROOT is there if start-stop-daemon is used. Try .
> /QLogitechMediaServer.sh config. Would love to see the output.
Again, just to be sure, there's no .CHROOT. I removed it.
Here's the config's output:
Code:
jolly wrote:
> Thank You digimaster for quick response.
>
> This is what I get from ./QLogitechMediaServer.sh restart:
>
>
> 26802
>
> 26801Strange thing. What about the output off . /QLogitechMediaServer.sh
config?
Send from my mobile Phone
*
maintainer of QLogitechMediaServer,
slartibartfast wrote:
> This is the server log with player source set to info logging. Streaming
> set to proxied.
I can reproduce on an Ubuntu with a receiver as player and can't say
anything definitive regarding cause.
Using wireshark - the stream is opened and lots of data (127kBytes) is
I thought with both LMS servers active you bring up the WebGUI on the
target server you want to move the player to and click the player drop
down and it will show the players on the other server. You then select
the player you want to move and you will be promted saying something
like the player
bpa wrote:
> At a guess the Echo downloads the whole podcast in one go whereas LMS -
> takes it in chunks - the chunks are larger if proxied.
>
> Some podcast servers don't like streaming with long pauses between gulps
> of data (127kbytes is about 6-8 minutes playback).The podcast size is
bpa wrote:
> I can reproduce on an Ubuntu with a receiver as player and can't say
> anything definitive regarding cause.
> Using wireshark - the stream is opened and lots of data (127kBytes) is
> downloaded immediately - then stream is playing.
> No more data is transferred while TCP
bpa wrote:
> At a guess the Echo downloads the whole podcast in one go whereas LMS -
> takes it in chunks - the chunks are larger if proxied.
>
> Some podcast servers don't like streaming with long pauses between gulps
> of data (127kbytes is about 6-8 minutes playback).I just tried searching
w3wilkes wrote:
> I thought with both LMS servers active you bring up the WebGUI on the
> target server you want to move the player to and click the player drop
> down and it will show the players on the other server. You then select
> the player you want to move and you will be promted saying
slartibartfast wrote:
> If it makes any difference the same thing happens with direct streaming.
> The podcasts play correctly on an Echo via Tunein.
At a guess the Echo downloads the whole podcast in one go whereas LMS -
takes it in chunks - the chunks are larger if proxied.
Some podcast
dolodobendan wrote:
> Again, just to be sure, there's no .CHROOT. I removed it.
>
> Here's the config's output:
>
> >
Code:
> >
> admin@192.168.1.1:/share/CACHEDEV1_DATA/.qpkg/LogitechMediaServer$
./QLogitechMediaServer.sh config
>
dolodobendan wrote:
> I'm happy, thank you. :)Hope Michael also gone make it for the other
> architectures. As I want to
keep the LMS as basic, as it's found on the website.
Send from my mobile Phone
*
maintainer of QLogitechMediaServer, QOptware-NG and QAutoSub.
Qnap TS-453a, with
slartibartfast wrote:
> The podcast size is around 27MB which would be around 1MB per minute.
>
> Sent from my SM-G900F using Tapatalk
I was using one which the headers said 41947266 bytes and duration
157320 secs
bpa's
> It's because of you, I decided to go to perl 5.28.
:o Oh my. Thank you!!!
digimaster wrote:
> Hope Michael also gone make it for the other architectures. As I want to
> keep the LMS as basic, as it's found on the website.
I'm pretty sure that other architectures will follow.
QLMS
digimaster wrote:
>
> Hope your happy with perl 5.28, as LMS then supports audio::scan.
>
I'm happy, thank you. :)
QLMS 7.9.2@2.03.21 x64 (digimaster) / QNAP 469L QTS 4.3.4
dolodobendan's Profile:
While idly gazing out of the window, I've just played this on a
Squeezeplay desktop with Wireshark in the background. The remote server
issued a very final looking "FIN" after transmitting about 7.1M bytes of
data in a period of 3 minutes. Play time was worth about 7 minutes, and
the player
bpa wrote:
> I was using one which the headers said 41947266 bytes and duration
> 157320 secsThat seems far too long 157320 secs is more than 43 hours.
Sent from my SM-G900F using Tapatalk
slartibartfast's Profile:
*
'How to add the Qnapclub store to the QNap App center'
(https://www.qnapclub.eu/en/howto/1)
'The latest QLogitechMediaServer version!'
(https://www.qnapclub.eu/nl/qpkg/545)
= QLogitechMediaServer version 2.03.31
= 19-02-2019
+ For the
bpa wrote:
> Did a quick hack so time displayed is correct but playback still stops
> after about 7 mins.
>
> I feel this stopping is about the server not liking the stream not
> "moving" for a number of minutes - the issue is how to "prove" it and if
> so - even harder, is there a
slartibartfast wrote:
> That seems far too long 157320 secs is more than 43 hours.
>
> Sent from my SM-G900F using Tapatalk
Interesting.
I took the 157230 secs from LMS (see 2 screenshots) - so I looked at the
XML source which shows
Code:
43:42
bpa wrote:
> Interesting.
>
> I took the 157230 secs from LMS (see 2 screenshots) - so I looked at the
> XML source which shows
> >
Code:
> >
> 43:42
>
> >
>
> This could mean LMS has a "minor" parsing issue which is mistaking a
> MM:SS
slartibartfast wrote:
> Any idea what song pos 6107345 means?
Usually the number of bytes read from the source - but I think if
transcoding/rate limiting is involved the source may be the trasncoding
chain although not sure.
slartibartfast wrote:
> That makes sense as the total length of the episode I listened to is
> 27626853 bytes and has a length of 29 minutes 22 seconds from the XML
> file. 6107345 would be around 6.5 minutes which is around the time when
> playback stopped. So for some reason LMS thinks that
slartibartfast wrote:
> Yes, 157320 seconds is exactly 43 hours 42 minutes. It must be a parsing
> error.
Did a quick hack so time displayed is correct but playback still stops
after about 7 mins.
I feel this stopping is about the server not liking the stream not
"moving" for a number of
bpa wrote:
> Usually the number of bytes read from the source - but I think if
> transcoding/rate limiting is involved the source may be the trasncoding
> chain although not sure.
That makes sense as the total length of the episode I listened to is
27626853 bytes and has a length of 29 minutes
dolodobendan wrote:
> I'm pretty sure I never deleted parts of the OS.
>
>
>
> If you mean by that "open terminal and type in start-stop-daemon", then
> yes:
>
> >
Code:
> > bash: start-stop-daemon: command not found
> > Should be fixed with
Hi,
so far I have been using LMS on old TS219 (arm) - the 7.7.2 SSTOS -> fix
routine.sh -> update 7.9.2 way. The NAS has died and I have replaced it
with 453Be (x86). Happy to discovered QLogitechMediaServer. Great
solution!
Unfortunately it doesn't work on my machine (453Be) so far.
H no so out off the box not.
Would suggested, install latest version.
Logon to ssh shel, go to .qpkg/LogitechmediaServer directory, and run
./QLogitechMediaServer.sh restart.
No look at the screen, and what its telling you.
Keep in mind first always try a clean installation.
And if you
36 matches
Mail list logo
