Notices

Something undocumented? Grepping for conjunction of "position" and "change" in the sources of libmafw, mafw-gst-renderer and mafw-shared yields nothing interesting. The only position callback is for responding to "get position" request, and that's what OMP uses (and the stock MP too).


I tried to reproduce the playback failure for 15 minutes by playing lots of videos from local storage and YouTube, to no avail, and I put away the N900. However, after going back to it some time later, I noticed that OMP is no longer open, and core dumps were saved for OMP and mafw-dbus-wrapper.

After that, upon the first attemp to play a video, the screen was black and nothing was happening. A few attempts later I got an error popup ("Unable to play media/Unsupported media") and that's what I 'm getting every time since then (have not restarted the device yet, killing mafw-dbus-wrapper does not help).

The error reported by the renderer on D-Bus is "couldn't start node", which apparently has its origin in "/usr/lib/gstreamer-0.10/libgstdsp.so". I have no idea what it means, but the problem does not seem tie lie in MAFW (unless it was the renderer doing funny things and breaking DSP for the whole system), because the camera app was crashing when trying to record a video (now it does not crash anymore, but the view goes black when recording and it still produces broken videos).

The only other clue I have found so far is "procwrap_detach: deprecated dspbridge ioctl", which appears in dmesg (I do not remember seeing it before) when trying to play a video using MAFW or when recording.

CSSU-thumb, no HD codecs installed.

xes, if you started dbus-monitor before playing a video and pasted its output after a failure happens, we could check if that's the same thing or just gather more info. Also check if video recording works and look for anything interesting in dmesg output.

so...

when mafw-gst-renderer is ~freezed, it seems to continue doing something with the last video i tried to start. (and uses a lot of ram ..reserved: 30-40MB)

As soon as i start again openmediaplayer without killing mafw-gst-renderer, if i place an strace to mafw-gst-renderer, i obtain:

writev(3, [{"l\2\1\1\223\0\0\0\274\2\0\0\"\0\0\0\6\1s\0\6\0\0 \0:1.477\0\0\5\1u\0!\0\0\0\10\1g\0\4uuis\0\0\0\0\0 \0\0", 56}, {"\6\0\0\0\2\0\0\0\0\0\0\0\202\0\0\0localtagfs::vi deos/%2Fmedia%2Fmmc1%2FFILM%2FcuteTube%2FIron%20Maiden% 20-%20Fear%20of%20the%20Dark%20-%20Rock%20in%20Rio%202013.mp4\0", 147}], 2) = 203
poll([{fd=4, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=12, events=POLLIN}, {fd=3, events=POLLIN}], 5, -1) = 1 ([{fd=3, revents=POLLIN}])
read(3, "l\4\1\1\24\0\0\0@\0\0\0\226\0\0\0\1\1o\0(\0\0 \0/com/nokia/mafw/source/upnpcontrolsource\0\0\0\0\0\0\0\0\2\1s\0\30\0\0\0c om.nokia.mafw.extension\0\0\0\0\0\0\0\0\3\1s\0\20\ 0\0\0property_changed\0\0\0\0\0\0\0\0\10\1g\0\2sv\ 0\7\1s\0\5\0\0\0:1.68\0\0\0\10\0\0\0activate\0\1b\ 0\1\0\0\0", 2048) = 188
read(3, 0x150fa0, 2048) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=12, events=POLLIN}, {fd=3, events=POLLIN}], 5, 0) = 0 (Timeout)
poll([{fd=4, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=12, events=POLLIN}, {fd=3, events=POLLIN}], 5, -1) = 1 ([{fd=3, revents=POLLIN}])
read(3, "l\1\0\1\0\0\0\0%\0\0\0\277\0\0\0\6\1s\0<\0\0\0com .nokia.mafw.renderer.Mafw-Gst-Renderer-Plugin.gstrenderer\0\0\0\0\1\1o\0$\0\0\0/com/nokia/mafw/renderer/gstrenderer\0\0\0\0\2\1s\0\27\0\0\0com.nokia.mafw. renderer\0\3\1s\0\n\0\0\0get_status\0\0\0\0\0\0\7\ 1s\0\6\0\0\0:1.477\0\0", 2048) = 208
read(3, 0x150fa0, 2048) = -1 EAGAIN (Resource temporarily unavailable)

Please note, i have just opened OMP and i'm still at the first window (music/video/radio/random)

In the meanwhile, dbus-monitor reports:

method call sender=:1.480 -> dest=com.nokia.mafw.playlist serial=53 path=/com/nokia/mafw/playlist/6; interface=com.nokia.mafw.playlist; member=get_size
method return sender=:1.152 -> dest=:1.480 reply_serial=53
uint32 53
method call sender=:1.480 -> dest=com.nokia.mafw.renderer.Mafw-Gst-Renderer-Plugin.gstrenderer serial=54 path=/com/nokia/mafw/renderer/gstrenderer; interface=com.nokia.mafw.renderer; member=get_status
method return sender=:1.327 -> dest=:1.480 reply_serial=54
uint32 6
uint32 2
int32 0
string "localtagfs::videos/%2Fmedia%2Fmmc1%2FFILM%2FcuteTube%2FIron%20Maiden% 20-%20Fear%20of%20the%20Dark%20-%20Rock%20in%20Rio%202013.mp4"


When everything works, dbus-monitor polls continuosly:

method call sender=:1.484 -> dest=com.nokia.mafw.renderer.Mafw-Gst-Renderer-Plugin.gstrenderer serial=121 path=/com/nokia/mafw/renderer/gstrenderer; interface=com.nokia.mafw.renderer; member=get_position
method return sender=:1.481 -> dest=:1.484 reply_serial=121
uint32 62
method call sender=:1.484 -> dest=com.nokia.mafw.renderer.Mafw-Gst-Renderer-Plugin.gstrenderer serial=122 path=/com/nokia/mafw/renderer/gstrenderer; interface=com.nokia.mafw.renderer; member=get_position
method return sender=:1.481 -> dest=:1.484 reply_serial=122
uint32 63
method call sender=:1.484 -> dest=com.nokia.mafw.renderer.Mafw-Gst-Renderer-Plugin.gstrenderer serial=123 path=/com/nokia/mafw/renderer/gstrenderer; interface=com.nokia.mafw.renderer; member=get_position
method return sender=:1.481 -> dest=:1.484 reply_serial=123
uint32 64
method call sender=:1.484 -> dest=com.nokia.mafw.renderer.Mafw-Gst-Renderer-Plugin.gstrenderer serial=124 path=/com/nokia/mafw/renderer/gstrenderer; interface=com.nokia.mafw.renderer; member=get_position
method return sender=:1.481 -> dest=:1.484 reply_serial=124
uint32 65
method call sender=:1.484 -> dest=com.nokia.mafw.renderer.Mafw-Gst-Renderer-Plugin.gstrenderer serial=125 path=/com/nokia/mafw/renderer/gstrenderer; interface=com.nokia.mafw.renderer; member=get_position
method return sender=:1.481 -> dest=:1.484 reply_serial=125
uint32 66
method call sender=:1.484 -> dest=com.nokia.mafw.renderer.Mafw-Gst-Renderer-Plugin.gstrenderer serial=126 path=/com/nokia/mafw/renderer/gstrenderer; interface=com.nokia.mafw.renderer; member=get_position
method return sender=:1.481 -> dest=:1.484 reply_serial=126
uint32 67
method call sender=:1.484 -> dest=com.nokia.mafw.renderer.Mafw-Gst-Renderer-Plugin.gstrenderer serial=127 path=/com/nokia/mafw/renderer/gstrenderer; interface=com.nokia.mafw.renderer; member=get_position
method return sender=:1.481 -> dest=:1.484 reply_serial=127
uint32 68
method call sender=:1.484 -> dest=com.nokia.mafw.renderer.Mafw-Gst-Renderer-Plugin.gstrenderer serial=128 path=/com/nokia/mafw/renderer/gstrenderer; interface=com.nokia.mafw.renderer; member=get_position
method return sender=:1.481 -> dest=:1.484 reply_serial=128
uint32 69





........fear of the dark?


PS:
I'm using: cssu thumb hd codecs kp52git
Just changed the "quick and dirty" OMP start script here:
http://talk.maemo.org/showpost.php?p...postcount=1563

when playing flac audio and OMP is on background and xterm windows is visible I see this in dbus-monitor:

it calling get_position every second.

now I looked at stock media player and it not doing any polling. when windows is activated (from task manager or unlocked screen) it call get_position only once. so I think it using some timer to update internal position every second until som stop/pause/error/background/lockscreen signal is not received.

so can be this implemented in omp? (sorry I cannot look at it, my devel machine with scratchbox not working :-()

xes, by "starting before playing a video" and "pasting after a failure" I meant the time span between starting a video and the moment at which you can be sure that the video which you just started will not be able to be played. What about camera recording and dmesg?

And as I have written before, I doubt it's a problem with OMP, so if I was you, I'd uninstall HD codecs, reinstall MAFW, GStreamer and any extra decoders, reset the Tracker database, and see if that fixes the problem.


Did you have ssh with dbus-monitor running somewhere else? If you have it on the same N900 as stock MP, you will not see it polling when another window is active, because stock MP has a way to detect whether its window is visible. If you quickly switch between stock MP's and terminals's window, you can perceive it as a one-time position check on window activation, but it is not what really happens.

You can check this even without ssh: simply leave the task navigator open so that you can see both the terminal and the stock MP at the same time. You should see the terminal scrolling every second with the same kind of output that you have pasted for OMP.

I have already written why I don't think it's such a good idea in the last paragraph here: http://talk.maemo.org/showpost.php?p...postcount=1567 (in the same post I have also written that a slider has to be visible for polling to occur, but I meant it in Qt terms, and was aware that OMP still does not behave exactly as the stock MP). What I think needs to be done is to find a way to detect visibility of OMP's window, and this should be sufficient.

@gidzzz
ok, i will start another debug session. (unfortunately, omp playing a video + dbus-monitor + tail syslog + strace... is a pretty hard set of tasks for the N900 cpu)

Talking directly about the problem, i don't think it's related to the hd codecs.
In fact, you said that you are experiencing the same behavior and you don't have the hd codecs installed.

My opinion is that there is a bug in mafw-gst-renderer or OMP sometimes leaves mafw-gst-renderer in a "strange" condition after the playback. ...But so far is just an idea.
Could you check the actions that omp does when closing a running video with the "back" arrow?

I started dbus-monitor in xterm and then activated OMP to foreground. I did same with stock MP. And in dbus-monitor there was no periodical polling when stock MP was activated and was playing flac files... Any idea?

I do not know if it's the same thing, that's what I wanted to check by comparing:

• output of dbus-monitor from the time when the playback failure occurs,
• ability to record a video after the playback failure,
• output of dmesg after the playback/recording failure,

but you have not provided any of that info. And I did not say a word about syslog or strace.

There are no obvious mistakes:

• pause playback (to generate a thumbnail),
• save current position,
• stop playback,
• restore renderer error policy to "skip-on-error",
• restore window orientation policy.

The stock MP causes a lot more D-Bus activity than OMP. Maybe there's so much output with the stock MP when switching windows that you cannot find the lines for which position polling is responsible?

And why do you insist on on checking it the hardest way? Try with SSH or activate the task switcher and watch the windows side-by-side. Or at least pipe dbus-monitor to something like "grep get_position -A 2" and really, really carefully watch the numbers.



Open Media Player 20140219-1 is out. It features some significant changes that were needed for lyrics and video thumbnails to work at all times, and should also make it possible to cleanly implement some interesting stuff like tags via RDS or voice (eSpeak). However, I'm not sure if any of the latter should belong to the core and might be better handled by a plugin system or a customizable shell script.

Now that this feature can be implemented, I wonder if that's really necessary. Were you aware of this: http://talk.maemo.org/showthread.php?t=39452? I do not know if it works well, as I don't have an easy access to something that supports RDS.

The changelog:

• UPnP widget uses whole screen width if playback indicator is hidden.
• Bluetooth and ringtone dialogs stay open for as long as it takes to obtain file details and allow operation to be cancelled in the meantime.
• Fixed paused video thumbnails being updated only when the video browser is open.
• Downloading of lyrics happens in the background even if Now Playing has not been opened yet.
• Improved reliability of media type detection in the UPnP browser.
• Use a separate color for lyrics status messages.
• Improved reliability of stop buttons and enabling/disabling of position sliders.
• Lots of changes under the hood.

At the moment of this writing, Thumb version is already downloadable, and the standard version should reach extras-devel soon.

An issue that still exists in the latest thumb version: when gPodder tries to play a podcast when OMP is closed, OMP opens and plays the file that was open when it last closed; if OMP's open the correct file is played.

is omp able to play streams piped from stdout?

@gidzzz - there is a long standing "feature" in OMP - trying to change the language while in playlist search mode (songs, etc) brings plyback window. That feature comes from https://gitorious.org/qt-mediaplayer...icator.cpp#L76

Now, my understanding is that no application should override system shortcuts unless really needed. Which is not the case here IMO.

Please advice on how to proceed (doing MR on gitorious seems too heavy for a one-liner patch)