two currents and a wish list

[huck]

Hi, new here, been reading some, but i hope this is the right place. I put it here because i am communicating via the http: interface.

first a probable bug. im win-xp, vlc-205

to replicate, "start vlc" below means "start vlc with the http interface running on port 8080"

start vlc, find a dir of mp3s, right click on it and select "add to vlc media players playlist", so then save that as a playlist, (<ctrl>-y ) with the name "test". close vlc.

start vlc again, find same dir, right click on it and select "add to vlc media players playlist", and start playing a file in it. now use media, open-file, and open that same test playlist you just saved. It should start vlc playing too, but if it nothing is started make sure something is playing.

it looks fine in the vlc playlist window, but now it gets interesting.

(i have a dns/host-entry for vlcl.my.lan pointing to the right machines ip address, you may want to use 127.0.0.1 instead in the below addresses.

now go look at http://vlc.my.lan:8080/requests/playlist.json
and notice there are TWO leafs marked current!!!!!!!!!!!!
this causes my perl/Tkx routine to do a real doubletake, and and the last one found is marked as the "current" leaf internally.

now outside this simple fault-replication, lets say i had other directorys between the hand loaded directory and the playlist, and if it is actually the first instance playing when all files in that directory are done, it will "fall into" and play from an intermediate directory, but if it was playing out of the "test playlist" and loop isnt set, it will stop playing..... hmmm...

Any hope??

Second, to start, let me describe a little what im doing.
i have perl/Tkx code designed to act kinda like the browser interface , but with no streaming, the host machine is plugged into my house-stereo, and i just need to control it.
its doing okish, long way to go still. My design principle is that there could be more than one of these going at once , "controllers in different rooms". it displays the playlst, highlites whats current (see above), has your standard <prev []stop/play/pause >next buttons, volume will be next. I kinda like that it keeps all dirs not containing current "closed"

I have created a new button series ">>skip to next dir in playlist", and "<<skip to prev dir in playlist". i had a cd player that did this and i loved it. i just kinda parse up/down the playlist and watch for the anything but the last token of the uri to change (skipping children nodes), and grab the proper id, and do a http://vlc.my.lan:8080/requests/status. ... &id=<right number>. I love it, "skip to next/prev show"(etree...). command=pl_next/pl_previous, just play something on its end, even if my app doesnt have the right/current playlist, they do what i want. but this "skip to" thing needs to know the most current playlist, (another controller or even the host console may have played something new, or changed the playlist). this means i need to update my playlist.json before i can do this "skip to" function. and ya know getting the playlist can take 4+seconds, (ok, it has 3000+ leafs) , (and can cause the vlc player to "hickup" at times too, yea i know you want logs, ill get there, im not complaining about it, yet...). This really ruins my "quality of experience" for my app. now i realize 99% of the time the playlist.json i have will be right, i just need to know what is current in the playlist.

hence if i may propose an extension, first have status.json include a playlist-last-modified field, it can be anything that can be unique and will change each time the playlist is modified, such as time-gmt or a even a just counter or real randomized number. if a json field is added to playlist.json that contains it too, i can compare the two and know if i need to request a new playlist and save my QoE rating. This would of course mean i need to get current from status.json, and request that a field called current (somewhere) be added with the <ID> of the current item playing. This way all i need to do is request status.json (which i do anyway).

third: when i do a status.json?command= it seems what i get back is the state BEFORE the command= is executed. in fact, even if i get a new status.json right away, it can contain the state pre execution of the command state, (this is where i get position, time, and volume from ), and i ask for this before i ask for playlist.json. so now i need to wait Two whole seconds after the eof of the ?command= just to get valid data. (waiting 1 second wasnt always enuf), again messing with that QoE. i would love it if the ?command= would wait until the command had finished, AND that any other machines that request status.json after the ?command= was issued got a status.json back that indicated there was a command in progress to tell me im going to need to update again soonish.

Fourth: this dell 610 runs at 50% when playing mp3s. and basically 0%-ish when not actively playing mp3s ... I know logs, when requesting playlist.json glitches the playback, its hitting 100%. ill get to the logs, hey, this is my first rant ....



Otherwise, *** *** thanks *** a whole whole lot ***

I used an older vlc to play "odd" videos before, and in putting vlc onto a rebuild of a friends machine i noted the 2.0.x version and started using it again. Thats when i came up with the idea of the perl,perl/tkx app. Its been mostly fun to play with, but at times exasperating as you might guess from the above. Its an old laptop thats the vlc-host-machine.

maybe i need to go to lua? instead of the http: interface, but ive been having fun getting exasperated with Tkx/Tcl, under perl. To do "interruptable" IO to keep that QoE, i wrote my own simple "wget"/LWP under TCL sockets/fileevent even. Im not ready to play with that yet.

[Jean-Baptiste Kempf]

You should file a bug about the first issue.
You should fix the second issue and send us a patch.
For the third part, this seems normal to me.
4th, you mean 100% of CPU usage to play a MP3?

[huck]

You should file a bug about the first issue.

ok, i think i did. #8314 , but i suspect you knew something
heh, been digging thru guts
"#warning Indexing input items by ID is unsafe"
"p_input->i_id = vlc_atomic_inc(&last_input_id);" "
input_item_t *p_item = input_GetItem( p_input );
if( p_item ) id = p_item->i_id;

ok whats wrong with pl_priv(p_playlist)->status.p_item->id? it seems all the playlist.json stuff is anchored to a playlist anyway. I do think i see how you can get a input thread running without a playlist tho, but the lua cant find it (i think)

You should fix the second issue and send us a patch.

i might, digging after the playlist current stuff game me some ideas , i need a break tho

For the third part, this seems normal to me.

heh , if i fix the second ill work around this too

4th, you mean 100% of CPU usage to play a MP3?

well, kinda yea. i have since noticed that besides playlist.json being able to max out the cpu, there is some other process that run periodically that eats everything else. it jitters then too, and if i do a playlist.json during that , i get a socket-eof before i get any data back. but that process had already started before i ran the playlist.json, and i notice it happening without running it even.

[huck]

I saw that this had been fixed

"
Resolution set to fixed
Status changed from new to closed

commit 5192a05dbb57338f9633b39a32309f6421f33a0e
Author: Francois Cartegnie <fcvlcdev@…>
Date: Sat Apr 13 15:04:15 2013 +0200

lua intf: httprequests: fix current (fix #8314)


Compare items ID, not paths which creates duplicates"

https://trac.videolan.org/vlc/ticket/8314#comment:1

but in updateing to 2.1.3 (yea always behind) i find that the fix is "bad"

the fix uses

Code: Select all

local current_item_id = vlc.playlist.current() ... if(current_item_id ~= nil) then if(current_item_id == item.id) then ..

instead of

Code: Select all

local current_item = vlc.input.item() ... if(current_item ~= nil) then if(vlc.input.item().uri(current_item) == path) then ...

the problem is that vlc.playlist.current actualy returns an input_item.id whereas the item.id it is testing against is a playlist_item.id

in digging around i see that it is common to think that vlc.playlist.current is returning a playlist_item.id.
for instance https://forum.videolan.org/viewtopic.ph ... 84#p399693
referencing code he created for his clipper.lua extension

while i would be happy with a new lua variable/function vlc.playlist.currentplaylistid(vlc.playlist.get()) i think the real resolution would be to fix vlc.playlist.current to return what i suggested above

Code: Select all

pl_priv(p_playlist)->status.p_item->i_id

im sorry i did not investigate this more thoroughly when i got the bug fix report. i have been using some custom lua to fix the problem
rather than testing vlc.input.item().uri(current_item) in the depths of the loops, i fetch it once and pass it into the subroutine calls

Code: Select all

local current_item = vlc.input.item() local current_item_name = "" if(current_item ~= nil) then current_item_name =vlc.input.item().uri(current_item) end local basePlaylist=httprequests.getplaylist() return parseplaylistfast(basePlaylist,current_item_name)

Code: Select all

parseplaylistfast = function (item,current_item_name) ... local path = item.path or "" ... -- Is the item the one currently played if( current_item_name == path) then result.current = "current" ...

and while that still suffers from the duplicate problem it processed much faster than the original code that looked up the current_input_item uri every time.

i use what must be "complicated playlists", where the input_item.id is nowhere near the playlist_item.id so the new method may show the current file as being in a wholly different directory that the one that has the current playing item.

Ok, so i am stuck on what to do next. i have a workaround that is somewhat faulty but does work for most of my purposes. yet i realize the new function is broken.

should i try to write up a new bug report? or somehow mark the old one as not actually fixed
https://trac.videolan.org/vlc/ticket/8314#comment:1

[huck]

This is the fix i propose

Code: Select all

330a331,345 > static int vlclua_playlist_current_playlist_id( lua_State *L ) > { > playlist_t *p_playlist = vlclua_get_playlist_internal( L ); > PL_LOCK; > playlist_item_t *p_pl_item=get_current_status_item(p_playlist); > int id = -1; > if( p_pl_item ) > id = p_pl_item->i_id; > } > PL_UNLOCK; > > lua_pushinteger( L, id ); > return 1; > } > 416a432 > { "currentplaylistid", vlclua_playlist_current_playlist_id },

that is a dif against vlc-2.1.3.tar\vlc-2.1.3\vlc-2.1.3\modules\lua\libs\playlist.c

it adds a new function vlclua_playlist_current_playlist_id and exposes it as vlc.playlist.currentplaylistid via vlclua_playlist_reg

Code: Select all

337c337 < local current_item_id = vlc.playlist.current() --- > local current_item_id = vlc.playlist.currentplaylistid() 458c458 < s.currentplid=vlc.playlist.current() --- > s.currentplid=vlc.playlist.currentplaylistid()

thats a diff against vlc-2.1.3.tar\vlc-2.1.3\vlc-2.1.3\share\lua\intf\modules\httprequests.lua

which uses the new function to get its values.

While i suspect that there will be a lot of places where someone wants to change vlc.playlist.current to vlc.playlistcurrentplaylistid i wasnt sure i wanted to bust anything that may actually be working.

i dug around a bunch and i think i have the right locking semantics in vlclua_playlist_current_playlist_id. i realize that the playlist id could change before the html was returned, well it was current when the request was started at least.

it still is costly because of all the callings callings (and locks) in httprequests. should this prove successful i would also propose a fix like in my above comment where vlc.playlist.currentplaylistid is only called once and its value passed down the parameter stack as the playlist tree is parsed. but then i run 2-3000 songs in my playlist all the time too.

this is what i figured out last time, but i nver got around to building a linux-vlc-compiler box. i got a little close then dedicated that box to wireshark instead. all ive got left are old slow boxes, but maybe its just something i need to get too. Or maybe someone can look at this and figure out real quick what to fix and try it on their build box first. ( i know the diffs are to 2.1.3 and not .4, but the changes should be rather simple even then, two inserts in playlist.c and two edits to httprequests.lua.

Im going to let this sit a little more, if i dont get any "bites" ill file a fresh bug report with the above suggestions included rather than referenced.

[Rémi Denis-Courmont]

There is no warranty that the input item ID is unique. It's mostly useless legacy stuff from the aging playlist code. Please don't use it in new code.

[huck]

There is no warranty that the input item ID is unique. It's mostly useless legacy stuff from the aging playlist code. Please don't use it in new code.

Im not sure i understand.

My suggestion is to open up a new lua function that returns the currently playing playlist_item_id because you cant match the playlist_item_id used by playlist.json to the input_item_id that vlc.playlist.current returns now.

Are you suggesting to totally drop the legacy vlc.playlist.current or am i missing something else?