logs archiveBotHelp.net / Freenode / #mopidy / 2015 / August / 13 / 1
adamcik
kingosticks: btw, we probably broke tunein when we ripped out the playlist handling from gstreamer
we probably want to find a way for mopidy to help backends that need to do this type of translation
probably just some util method
(Action) was looking for cases of media scan failing but track being playable
and came across this, but do give me such an example if you have one :-)
jodal
hah, the irony. fastly uses globalsign to get us a wildcard cert for fastly use, only after globalsign no longer wanted to provide us with a wildcard cert, just a cert with a bunch of SANs.
https://dl.mopidy.com/pimusicbox/ -- moved from akamai+rackspace files to fastly+our server. now with tls. dl speed up from ~2MB/s to 12MB/s on my 100Mbit at home. getting 39MB/s at work. \o/
and we have a trust chain through tls plus sha256 checksums of the files that we didn't use to have
https://www.mopidy.com/ -- moved from (github pages|our server|cloudflare adding tls) to (github pages|fastly adding tls)
https://pyspotify.mopidy.com/ -- moved from (readthedocs|our server|cloudflare adding tls) to (readthedocs|fastly adding tls)
https://docs.mopidy.com/ -- moved from (readthedocs|our server|cloudflare adding tls) to (readthedocs|fastly adding tls)
https://discuss.mopidy.com/ -- moved from (our server|cloudflare) to (our server|fastly)
fun to see the traffic start hitting a new CDN seconds after I flip it in the cloudflare DNS :-)
http://apt.mopidy.com/ -- moved from (our server) to (our server|fastly)
adamcik
jodal: I'm actually wondering if we should just revert the playlists out of gstreamer change for 1.1.1 and re-add it in 1.2.0 with the helpers tunein etc will need
jodal
won't it work to make -Stream scan the url it finds to check if its playable or another playlist and then recurse?
adamcik
yes, but that would only fix stream
not tunein
alternative is to check with kingosticks if we can do a quick tunein release to make it handle the recursion on it's own
but longer term I do think we want mopidy to provide something for extension like tunein
jodal
ok, so lib-ify the stream stuff, make it handle recursive playlists, and make other similar extensions use it too
sounds like food for 1.2, yes
adamcik
that's the ideal fix imo
and also have it correctly handle streams that produce audio but can't be metadata scanned in time
in other news we might have some one willing to give runtime configuration a go :-)
jodal
adamcik: can you update the issue with as detailed as possible plan for what to do?
adamcik
will look at it when I get back from work
or that was the plan at least
I don't really have that much details planed beyond having some way for actors to get config changed events
kingosticks
i'll be honest, i've not even tried to use tunein since those playlists changes. i totally forgot
and +999 for runtime config changes
jodal
adamcik: I was still thinking about streams and playlists, not runtime config
kingosticks
in the back of mind nothing had changed i the eyes of tunein. does a scan, fails, falls back to the hacky tunein parsing
in*
but that was based on no real information
adamcik
does the hacky thing do playlists?
jodal: ah
kingosticks
yes
at some point i ripped out the mopidy playlist parsing (in some cases making it less strict)
malformed playlists were giving me grief
jodal
kingosticks: maybe we could get those merged back together in a mopidy.plparser or something in 1.2?
kingosticks
that'd be lovely
assuming my dreams of totem playlist parses are still a way off
parser*
jodal
gather together enough example/broken playlists and the expected result, and make the test suite prove that the implementation is good enough
in my mind, totem is only an option after gst1+pygi has been done
which only depends on gapless getting merged now, since we don't want to change all gst code while the gapless branch exists, also changing a lot of gst code
kingosticks
i believe your mind is correct
jodal
...because the modern way to interface with totem plparser is to use pygi
I assume they have some old unmaintained bindings for pre-pygi too
kingosticks
ok, let me just get a handle on how broken (if at all) mopidy-tunein is
jodal
trygveaa: the mopidy-spotify-tunigo issue: it would be interesting to know if there's anything in the mopidy log about tunigo returning bad data to mopidy core or something. I guess it might be the 1.1 validation code that messes with tunigo.
jelle
btw the mopidy + mopidy-spotify 1.2 works flawless here!
*the new
jodal
jelle: 2.0 I assume? good to hear! haven't been that much feedback on the new mopidy-spotify
jelle
jodal: yeah something new ;)
the latest and greatest
jodal
I haven't packaged it for debian yet... got to backport python-cffi first
jelle
ah that sounds less fun
jodal
hopefully just a rebuild
was no problem with 0.8.6, but now I need 1.0+
jelle
yeah Arch Linux has 1.1.2 so that's new enough
now I soon need to allocate time to figure out how I can support adding songs to a playlist with mopidy :-) (because that's my only missing feature)
jodal
jelle: through MPD it is almost done... the PR just need one last round of fixes from the contributor
jelle: and the mopidy-mobile client already supports it
but... uhm... there's a couple of missing pieces in mopidy-spotify
should be quick to fix
and lot more interesting to fix with the MPD playlist editing support in
jelle
I was waiting n the MPD PR, then I want to start looking into the missing pieces in mopidy-spotify
kingosticks
who wants to add playlist editing to musicbox-weblcient? go on! someone!
worth a try
jelle
I don't use it ;)
kingosticks
not an issue!
theres nothing more fun than supporting something you dont use
jelle
I like the idea of controlling my music via my phone for my whole house though
I actually have my openelec box on the whole day, so would be nice to have mopidy running on it and then output audio via spdif to my stereo
or just yet another arm device with mopidy on it :p
jodal
I wonder what's needed to run mopidy on openelec
jelle
sounds like a good excuse to buy an arm board + lcd panel
kingosticks
is openelec the one they strip everything out?
jelle
kingosticks: well they basically made their own distro + kodi
kingosticks
oh, so not debian
jelle
nope
kingosticks
or raspbian
right
jelle
that's why it's fast
(Action) ducks
adamcik
xbmc/kodi has had this bad habbit of bundling libs in bad ways to make things work
jelle
jodal: I assume a lot of packaging, it has python, so it will need all the deps
kingosticks
i thought i tried it when the rpi1 came out and didnt notice any difference
jelle
adamcik: like ffmpeg :p
kingosticks
but maybe that was something else
adamcik
gstreamer and xbmc had conflicting versions of libtag at least
kingosticks
yeh, that is annoying
jelle
well it would be cool, since you could use a normal MPD addon for kodi to control mopidy
jodal
but debian have an xbmc/kodi with debian-ffmpeg today, doesn't it?
adamcik
debian has xbmc/kodi for debian
kingosticks
i tried to use a kodi mpd addon but it was agonisingly slow
jodal
(where ffmpeg == (ffmpeg, libav))
adamcik
or whatever they call it with sane packaging
« prev 1 2 next »