LMS:
Logitech Media Server Version: 7.8.0 - 1395409907 @ Thu Mar 27 13:20:53 PDT 2014
Hostname: xxxxx
Server IP Address: xxx.xxx.xx.xx
Server HTTP Port Number: 9000
Operating system: Debian - EN - utf8
Platform Architecture: i686-linux
Perl Version: 5.18.1 - i486-linux-gnu-thread-multi-64int
Database Version: DBD::SQLite 1.34_01 (sqlite 3.7.7.1)
Total Players Recognized: 1
Linux Server:
Running on Linux 3.11-2-486 #1 Debian 3.11.8-1 (2013-11-13) i686 GNU/Linux
The server only runs LMS and a command line podcatcher automated via cron jobs.
Media Folders:
home/soleserveruseraccount/media/podcasts
home/soleserveruseraccount/Music
Playlist Folder:
home/soleserveruseraccount/media/playlists
Hardware:
Original Slim Devices Squeezebox (the one with wireless), connected to an 802.11n access point via short Ethernet cable
Both the Linux server and Squeezeserver access point are on the same network set to static IPs, outside the DHCP range.
Via Webmin, added the user squeezeboxserver to the soleserveruseraccount group.
Set permissions with chmod -R 0777 to the /playlists, /podcasts, and /Music directories
Problem:
I only use the Squeezebox to listen to long-format podcasts while showering. I usually am not at the end of one when I'm finished, so I pause it and turn the Squeezebox off. The next morning, I turn it on, hit play and... nothing. I go to the LMS webpage and see the playlist pane is again Empty.
I thought I had solved this recently by adding a dedicated Playlist folder, along with setting the permissions to the folders as listed above. The marginal success is that the playlist of two podcasts I created yesterday was successfully written as an m3u file and can be re-accessed within the web interface, but the problem remains: the paused position within the file (bookmark, if you will) is not kept and the file begins at the start, rendering it doubly pointless as the server wipes out both the playlist selection (Now Playing) and the bookmarked pause spot. I assume this happens when the rescanning occurs overnight, but this can't be 'as designed', is it?
I'm now forced to remember the position of where I paused the day before, pull up the and re-add the playlist next morning, play the correct file and re-position the file at the spot I have to remember, as the system can't seemingly be bothered to do.
What am I missing here?
Logitech Media Server Version: 7.8.0 - 1395409907 @ Thu Mar 27 13:20:53 PDT 2014
Hostname: xxxxx
Server IP Address: xxx.xxx.xx.xx
Server HTTP Port Number: 9000
Operating system: Debian - EN - utf8
Platform Architecture: i686-linux
Perl Version: 5.18.1 - i486-linux-gnu-thread-multi-64int
Database Version: DBD::SQLite 1.34_01 (sqlite 3.7.7.1)
Total Players Recognized: 1
Linux Server:
Running on Linux 3.11-2-486 #1 Debian 3.11.8-1 (2013-11-13) i686 GNU/Linux
The server only runs LMS and a command line podcatcher automated via cron jobs.
Media Folders:
home/soleserveruseraccount/media/podcasts
home/soleserveruseraccount/Music
Playlist Folder:
home/soleserveruseraccount/media/playlists
Hardware:
Original Slim Devices Squeezebox (the one with wireless), connected to an 802.11n access point via short Ethernet cable
Both the Linux server and Squeezeserver access point are on the same network set to static IPs, outside the DHCP range.
Via Webmin, added the user squeezeboxserver to the soleserveruseraccount group.
Set permissions with chmod -R 0777 to the /playlists, /podcasts, and /Music directories
Problem:
I only use the Squeezebox to listen to long-format podcasts while showering. I usually am not at the end of one when I'm finished, so I pause it and turn the Squeezebox off. The next morning, I turn it on, hit play and... nothing. I go to the LMS webpage and see the playlist pane is again Empty.
I thought I had solved this recently by adding a dedicated Playlist folder, along with setting the permissions to the folders as listed above. The marginal success is that the playlist of two podcasts I created yesterday was successfully written as an m3u file and can be re-accessed within the web interface, but the problem remains: the paused position within the file (bookmark, if you will) is not kept and the file begins at the start, rendering it doubly pointless as the server wipes out both the playlist selection (Now Playing) and the bookmarked pause spot. I assume this happens when the rescanning occurs overnight, but this can't be 'as designed', is it?
I'm now forced to remember the position of where I paused the day before, pull up the and re-add the playlist next morning, play the correct file and re-position the file at the spot I have to remember, as the system can't seemingly be bothered to do.
What am I missing here?