Differentiate meta_changed calls?

[pnon10s]

Hello everyone,

I have spent some time learning Lua in the VLC environment and wrote an extension called Resume Media V2, which is listed in the Addons Extensions page. The extension fairly successfully detects a stopped video, stores the positions in a table and then resumes the video when it restarts.

I have been able to blindly use meta_changed calls to detect a video stop or start event. For a video (mp4's), there is a flurry of calls when it starts playing, and a few when it stops. So, I just grab the first one and ignore the rest for a short period. This has worked for videos.

I noticed with (at least) audio mp3's that there is often a continuous series of calls to meta_changed every second or so while the audio is playing. Without a way to determine the reason for the calls, I am forced to respond to them in case one is a stop event and I would need to save the position.

Is there any way to differentiate the calls to meta_changed? Specifically, I want to know if the user pushed the stop button. The input.is_playing flag seems to always be true when meta_changed is called and input_changed is not triggered for a stop event.

I am considering saving the audio position every 15 seconds or so while the media is playing instead of saving for each call to meta_changed. Ideally, I only want to save when the media stops or changes or VLC closes.

I could wait until the series of calls to meta_changed stops, but without a timer there would then be no automatic callback to regain control and save the last position.

Thanks for your help!!
Rocky

[fizzebu]

Hey,

first off I need to tell you that I took your code as inspiration, so thanks for that

So if I understand you correctly you can save the position of an audio file when it's changing (input_changed) to another file and also when VLC closes (deactivate). Why not just save the position in memory and only write it if those events occur? Or is input_changed called when the new mp3 is already playing? That would make more sense, grammar wise.

[pnon10s]

Thanks!

If a user has my table dialog open and she presses the stop button in VLC, I want her to see the position update immediately in the table. The way it is now for some audios, she will see a running continuous update with each call to meta_changed. I can ignore calls for, say, 15 seconds to save writes, but then the saved position is not as precise and it still looks like I'm not in control, which I'm not. If I just hold the last value in memory, she will not see the change when she presses stop, which is not correct either. I saw some of the back an forth talk about timers and I have to admit that a timer would allow me to write that last value to the table when it is clear that the meta_changed calls have stopped.

Or....if there was a way to tell why a particular call to meta_changed was made (rule out or rule in a stop event.)
Which begs the question, why is meta_changed called if it doesn't want to reveal itself? Could it have an argument pointing to the change in meta? I tried adding a couple of arguments to the function, but they are always nil. Would it be wasting time to parse all the meta data each call to see what's changed? The only things that should be changing continually are real time stuff like packets read, etc. But that's true for videos also. Is there a clever way to see back to the caller to try to differentiate callers? If there is a player-listener, is there a player_changed function? I tried several function name variations, but none were called.

[fizzebu]

Oh, I see. I can't help you with that, but I hope somebody can
I think mederi would know what's up, he's like a VLC lua extension pro.

[mederi]

You would need the vlc.var.add_callback(input, "intf-event", input_events_handler) that has been removed from VLC-2.1+. The add_callback() could be restored in the future as it is very useful function.

You just need to find a way that works the best or works at all. You probably should differentiate input_changed() and meta_changed(): input_ is called when starting and stopping playback and meta_ is called several times between these input_s. You can test the status:

Code: Select all

vlc.input.item() vlc.input.is_playing() vlc.playlist.status() vlc.var.get(vlc.object.input(), "state")

All information (e.g. duration) is not available immediately when starting a media. You could count calls in meta_changed() and perform an action not in the first call but once later (e.g. in the 5-th call).

You can only try to catch time position when stopping a media. The periodic activity of extension is not possible without the add_callback().

[Etoh]

An alternative approach would be to make your LUA script an interface script as this can use vlc.misc.mwait() to loop and wait, but this could be considered too hacky. One issue for interface scripts is knowing when to close - see https://forum.videolan.org/viewtopic.php?f=29&t=119738

[pnon10s]

Thank you, mederi.

State = 4 is the stop flag I needed. Not sure how that one stayed under my radar.

Thanks to everyone else for your helpful input.

Thank you! Thank you!

[pnon10s]

Maybe this will help someone else (...and I hope someone can prove me wrong.)

Issue:
If you open an extension while a media is playing, the extension cannot detect the next stop event for that media.

Discussion:
If you open an extension while a media is playing, then when you stop the media, the call to meta_changed that occurs has a mysterious value of nil for vlc.object.input(). Therefore you cannot test the state value. This is not true if the extension is active when the media starts.

Ironically, you can test vlc.object.input() on activate, and it is there! If you 'cleverly' try to save that object in anticipation of meta_changed being called when the media stops, it does not have (at least) the correct time information.

I had been allowing my Resume Media extension to automatically resume a media if Resume Media was opened while the media was already playing (which it could do.) But then it turns out I cannot detect the stop time of the media after that because of the above issue. So, for now, I have disallowed this automatic resume feature.