Feature #875
Extended M3U support
0%
Description
As described on the wikipedia page for the m3u format: https://en.wikipedia.org/wiki/M3U
I need something like this:
#EXTM3U #EXTINF:419,Alice in Chains - Rotten Apple Alice in Chains_Jar of Flies_01_Rotten Apple.mp3
I tried making a quick playlist using youtube-dl. Seems that audacious can use the links given by `-g` option quite well though. The problem is that I would like to have the file name not the url. I usually do something like this:
play=/tmp/playlist.m3u youtube-dl -g $link >> $play audacious --qt $play & > /dev/null 2>&1
On the other hand, if I use shorten links, generated by something a bit more complex, but faster (not to mention more readable output):
echo "#EXTM3U" > short.m3u youtube-dl -j --flat-playlist https://www.youtube.com/playlist\?list\=PLURsDaOr8hWWGebP8AGmA3Wu2WAQEHFUc | jq -r '.title, .url' | sed -e '2~2s_^_https://youtu.be/_' -e '1~2s_^_#EXTINF:,_' >> short.m3u
I get something like this:
#EXTM3U #EXTINF:,My Chocolate Croissant Was Supposed To Be Perfect... https://youtu.be/HQeIivIacJc #EXTINF:,I Learned How To Temper Chocolate... (science included) https://youtu.be/3-EKcYqKEec #EXTINF:,I Tried "Sous-Vide" to Temper Chocolate... (best move ever) https://youtu.be/--KcoWb8ZD4 #EXTINF:,I Designed Custom Chocolate Bars Using Thermoforming... https://youtu.be/O5SwGr-84c4
The generated playlist seems completely fine on vlc, on audacious on the other hand it simply... well, gives an error: `File format not recognized`
History
#1
Updated by John Lindgren over 5 years ago
Updated by - Category set to plugins/m3u
- Subject changed from m3u file: metadata is ignored, short links do not work to Extended M3U support
- Tracker changed from Bug to Feature
That's the "Extended M3U" format, we don't support that currently.
And your short links point to HTML pages, how exactly did you expect Audacious to "play" those?
#2
Updated by Raitaro Hikami over 5 years ago
Updated by Ok so what kind of format does audacious support exactly? Should I copy the ones found in .config/audacious/playlists?
Again, `vlc https://youtu.be/HQeIivIacJc` works :)
#3
Updated by Raitaro Hikami over 5 years ago
Getting the full link from that I get this loooooong thingy here. But whatever, this is to be used for streaming some stuff. The issue is this links is very long and takes a while to be generated vs the nice and quick js option :(
▶ youtube-dl -g https://youtu.be/HQeIivIacJc https://r1---sn-pouxga5o-vu2l.googlevideo.com/videoplayback?signature=58109388B28D71A5815495CB4827A2D73CAA7F56.82E7968B3696D80553E47011C32B8E3C63987695&fvip=3&ratebypass=yes&requiressl=yes&sparams=dur%2Cei%2Cid%2Cinitcwndbps%2Cip%2Cipbits%2Citag%2Clmt%2Cmime%2Cmm%2Cmn%2Cms%2Cmv%2Cpl%2Cratebypass%2Crequiressl%2Csource%2Cexpire&itag=22&ei=V6ByXNWkA9fk7gOn_6_4BQ&key=yt6&id=o-AAwXENMdGgnmEGU_QIkXjRdcuhutGvT1ZLgqYbppgiBJ&lmt=1550360255567520&mn=sn-pouxga5o-vu2l%2Csn-c0q7lnsl&c=WEB&ipbits=0&mm=31%2C29&txp=5532432&initcwndbps=186250&pl=24&mime=video%2Fmp4&mt=1551015881&ip=94.176.148.35&ms=au%2Crdu&expire=1551037623&mv=m&dur=585.026&source=youtube
Would be cool to pipe btw... `youtube-dl -g https://youtu.be/HQeIivIacJc | audacious --qt`
#4
Updated by Raitaro Hikami over 5 years ago
🤞😤
#5
Updated by Jim Turner over 5 years ago
Updated by Supporting extended m3u playlists does not appear to be difficult. Here's a patch to m3u.cc to do just that that seems to work for me. It also adds a checkbox to the plugin's [settings] labeled "Save in Extended M3U format" []. It will load either normal or extended playlists regardless.
Regards,
Jim
#6
Updated by Raitaro Hikami over 5 years ago
Jim Turner wrote:
Supporting extended m3u playlists does not appear to be difficult. Here's a patch to m3u.cc to do just that that seems to work for me. It also adds a checkbox to the plugin's [settings] labeled "Save in Extended M3U format" []. It will load either normal or extended playlists regardless.
Regards,
Jim
So... I assume I will have to apply the diff in this: https://github.com/audacious-media-player/audacious-plugins/blob/master/src/m3u/m3u.cc
Then I need to configure and make install the repo itself, right?
#7
Updated by Raitaro Hikami over 5 years ago
To be fair I tried.
To build audacious I did:
TPUT=/bin/true ./configure --prefix=/usr --enable-qt --disable-gtk &&\ make sudo make install
For plugins:
TPUT=/bin/true ./configure --prefix=/usr --disable-wavpack --with-ffmpeg=none --enable-qt --disable-gtk &&\ make sudo make install
And I just get
ERROR plugin-init.cc:147 [start_required]: No output plugin found. (Did you forget to install audacious-plugins?)
Not sure why so I simply `sudo make uninstall` and reinstalled audacious normally and not it works. (-H works btw)
Ah well, will be waiting for the support to trickle down in my ppa ¯\_(ツ)_/¯
#8
Updated by John Lindgren over 5 years ago
Jim Turner wrote:
Supporting extended m3u playlists does not appear to be difficult.
The problem is that refreshing the playlist will throw away the info from the extended M3U. We need a way (for example, a flag in the Tuple class) to mark info that came from a playlist (cuesheet or extended M3U) rather than from the audio file itself.
#9
Updated by Jim Turner over 5 years ago
- File playlist-data.cc.diff playlist-data.cc.diff added
@John: That's what the playlist-data.cc part of my Bug#878 patch addresses. BTW, I've replaced the scanner.* parts of that patch with your fix for that issue and it seems to work fine now, thanks! I'm including an update to the playlist-data.cc patch here that incorporates that change, see attached.
@Raitaro: Sry you're having trouble building Audacious, but I actually was addressing that patch toward the developers. Here's how I build Audacious:
1) Make sure you have all the "dev" vsns of the required libs:
sudo apt-get install git automake build-essential libasound2-dev \
libavformat-dev libbinio-dev libbs2b-dev libcddb2-dev libcdio-cdda-dev \
libcue-dev libcurl4-gnutls-dev libdbus-glib-1-dev libfaad-dev libflac-dev \
libfluidsynth-dev libgl1-mesa-dev libgtk2.0-dev libguess-dev \
libjack-jackd2-dev liblircclient-dev libmms-dev libmodplug-dev libmp3lame-dev \
libmpg123-dev libneon27-gnutls-dev libnotify-dev libpulse-dev \
libsamplerate0-dev libsdl2-dev libsidplayfp-dev libsndfile1-dev libsoxr-dev \
libvorbis-dev libwavpack-dev libxml2-dev libsndio-dev libswscale-dev libdvdread-dev libdvdnav-dev
2: UNINSTALL all your existing Audacious packages from your distro (it shouldn't delete your /home/you/.config/audacious files - Tar 'em up to be SURE)!
3):
mkdir audacious; git clone git://github.com/audacious-media-player/audacious.git audacious
mkdir audacious-plugins; git clone git://github.com/audacious-media-player/audacious-plugins.git audacious-plugins
5):
cd audacious
./autogen.sh
./configure --prefix=/usr/local [--enable-qt]
make -j2
sudo make install
cd ../audacious-plugins
./autogen.sh
./configure --prefix=/usr/local
make -j2
make install
cd ..
/usr/local/bin/audacious
Good luck!
Jim
#10
Updated by Raitaro Hikami over 5 years ago
@Jim
Thank you for the build script. What I did to get the devs was compiling, see what I was missing, and compiling again, which I don't think I did well.
#11
Updated by John Lindgren over 2 years ago
Just linking back to #1173 where there was some additional discussion. The issue of how to distinguish different sources of Tuple data (e.g. ID3 tag, extended M3U, or cuesheet) remains.
My suggestion would be to add some additional Tuple fields (Tuple::ExtTitle, Tuple::ExtArtist, etc.) which would hold the info from the extended M3U. Then e.g. Tuple::get_str(Tuple::Title) would also optionally look up Tuple::ExtTitle, similar to the existing FallbackTitle logic.
I think there's an opportunity for some nice cleanups here. We could, for example, make use of the new "Ext" fields for cuesheet support, and get rid of the whole CueCache workaround.
#12
Updated by Jim Turner over 2 years ago
John, something else I noticed in additional testing with the official Audacious playlist format (.audpl) is that the same metadata refresh issue you mentioned happens there as it does with my ext-m3u patch (m3u.cc), so I'm assuming that it's working as designed for playlists (cue-sheets work completely differently and don't suffer this issue). Therefore, I doubt the need for the extra tuple fields (assuming that ext-m3u metadata should work same as other "playlist" plugins) - or are you wanting it to work more like cuesheets?
I see what you're saying a/b blanking a field, as I ran into this awhile back while working on something unrelated in song-info updating and discovered that blanking simply left it unchanged ant that I had to enter a space in order to make it "blank", but didn't think anything amiss at the time, but now I realize that the correct behaviour is to reset it to it's "default", in the case of Title, back to the entry's file-name. Not sure off top of my head how to fix that in the patch or if it would need fixing somewhere else though.
