[ANNOUNCE] Alpha release of Open Media Player - Page 157 - maemo.org

gidzzz | # 1561 | 2014-01-02, 23:16 | Report

Originally Posted by sixwheeledbeast View Post

I would guess it's the same package but thumb compiled.

That's right, the purpose of my repository is to provide easily installable Thumb-compiled packages from extras-devel.

Edit:

Originally Posted by xes View Post

Just verified the latest update. Sorry, the problem is still there.
Now the message concerning the position has disappeared but some video still can't be played and when it happens syslog reports:

That's to be expected, as I have not yet done anything about the playback failure. As you have observed, it also affects the stock player, thus I believe it is a problem in MAFW and it might be impossible to work around it in OMP.

I cannot play some videos from time to time, but IIRC both players should immediately show an error in that case and rebooting helps. No 30-second delays or endless dots. Maybe reinstalling some MAFW-related packages would help? Or resetting Tracker database? Oh, and I don't have the HD codecs installed (using N900 mainly for music).

Last edited by gidzzz; 2014-01-02 at 23:56.

The Following 2 Users Say Thank You to gidzzz For This Useful Post:
freemangordon, xes

xes | # 1562 | 2014-01-03, 00:07 | Report

@gidzzz
Btw, with the position fix it seems to work better.. and the number of retries you are required to do before obtain the video are really decreased.

xes | # 1563 | 2014-01-03, 10:15 | Report

Further tests..

"stracing" openmediaplayer i have discovered that when a video does not starts there is an error "resource not available" calling mafw-gst-renderer.

Instead reboot, i have killed mafw-gst-renderer and tryed again the play.
Voilà! Video is working!

Until the thing is fixed, (WARNING: quick and dirty solution..) i have replaced openmediaplayer with a script that kills mafw-gst-renderer at every start, something like:

#!/bin/sh
kill -9 $(busybox ps |grep mafw-gst-renderer | grep -v grep | awk '{ print $1}')
openmediaplayer.orig $@
kill -9 $(busybox ps |grep mafw-gst-renderer | grep -v grep | awk '{ print $1}')

EDIT:
Now the scripts kills mafw-gst-renderer also after OMP exits.
This avoids that a monster mafw-gst-renderer process of 30/40MB remains loaded in memory (when hanged)

Last edited by xes; 2014-01-09 at 22:19. Reason: Script changed

The Following 7 Users Say Thank You to xes For This Useful Post:
Estel, freemangordon, fw190, gidzzz, mr_pingu, peterleinchen, Sohil876

Estel | # 1564 | 2014-01-03, 19:31 | Report

As I reported some time ago, kill mafw-dbus-wrapper also does the trick, i.e. makes unplayable videos playable without rebooting. Of course xes's solution got much more sense (I think), just wanted to note it, in case it could be important.

/Estel

The Following User Says Thank You to Estel For This Useful Post:
xes

pali | # 1565 | 2014-01-08, 20:14 | Report

Originally Posted by freemangordon View Post

There is no need, see http://talk.maemo.org/showpost.php?p...postcount=1545

This is only half solution. MAFW will for each log line call function via pointer - which is IMHO slow and using CPU... This will only reduce IO for syslog file.

Originally Posted by gidzzz View Post

A small update (20140102; should enter extras-devel shortly, Thumb version already available):

Disabled radio mode fallback for local videos.
Stricter checks regarding starting/stopping of media position polling.
Updated translations.

OMP did not perform enough checks to properly decide when to start/stop position polling, but I've just fixed this. I am pretty sure this problem was much older than one year.

However, recent changes do not prevent OMP from appearing in syslog, they only make it appear there when polling is really required. To make it disappear completely, g_debug()s in mafw-dbus.c have to be disabled, as all requests to MAFW from applications using mafw-shared for that seem to go through functions like mafw_dbus_send_async() and are logged there.

IMO recompiling libmafw-shared0 is a good idea, as I have never found those messages to be useful, and other applications would also be silenced. If recompiling poses a problem, I can disable OMP's messages by merging this (what freemangordon suggested): https://gitorious.org/qt-mediaplayer...452da041988600.

Is it not possible or not desired to upload the modified version to extras?

P.S. Sorry for being so absent lately, I still don't have my laptop.

Still recompiling MAFW without DEBUG is not final solution. There still will be lot of dbus calls (because that functions between MAFW daemon and OMP using dbus) which consume CPU... and dbus is slow. I think that polling should not be used over dbus.

The Following User Says Thank You to pali For This Useful Post:
Estel

freemangordon | # 1566 | 2014-01-08, 20:53 | Report

Originally Posted by pali View Post

This is only half solution. MAFW will for each log line call function via pointer - which is IMHO slow and using CPU... This will only reduce IO for syslog file.

TBH I don't think 10 or even 100 calls per minute will eat that much CPU. That call through a function pointer will be about 20 instructions at most, includeing the final BX LR - so 20-30 CPU cycles. Syslog IO won't be increased as glib checks the log flags and simply returns without doing any IO. In that regard - we should revert PA log to syslog patch in CSSU :P

Originally Posted by

Still recompiling MAFW without DEBUG is not final solution. There still will be lot of dbus calls (because that functions between MAFW daemon and OMP using dbus) which consume CPU... and dbus is slow. I think that polling should not be used over dbus.

Now, what I miss so far is *why* mafw spits to syslog when called from OMP, but does not when stock MP uses it. I think this is the question to be answered first, I bet the solution to the problem will become clear once we have that.

The Following 3 Users Say Thank You to freemangordon For This Useful Post:
Estel, gidzzz, sixwheeledbeast

gidzzz | # 1567 | 2014-01-08, 23:45 | Report

Originally Posted by pali View Post

Still recompiling MAFW without DEBUG is not final solution. There still will be lot of dbus calls (because that functions between MAFW daemon and OMP using dbus) which consume CPU... and dbus is slow. I think that polling should not be used over dbus.

If not over D-Bus, then how? I believe there is no other sensible way to check playback position. Stock MP also uses D-Bus for that.

And do you really think that exchanging an integer over D-Bus once per second has any noticeable impact when watching a movie or listening to music? Polling is enabled only when the screen is unlocked AND there's something playing AND you are in Now Playing window AND position slider is visible.

IMO the only possible tweak is to reduce the frequency of polling and predict what the playback time should look like in between. Polling still has to take place in case there's some delay in playback and doing it every 5 seconds instead of 1 is a negligible saving to an already negligible matter. Moreover, it comes at the cost of worse synchronization and increased complexity.

The Following 2 Users Say Thank You to gidzzz For This Useful Post:
Estel, sixwheeledbeast

xes | # 1568 | 2014-01-09, 00:40 | Report

Anyway, please don't forget that the syslog messages are just the secondary effect that apperared evident while checking why the playback wasn't starting.
In that situation the phone hasn't an high cpu load and seems to react pretty well. (in fact, the polling doesn't seems to create too much speed problems)

The first and real trouble is with mafw-gst-renderer that sometime is freezed not allowing the playback.

The Following User Says Thank You to xes For This Useful Post:
Estel

pali | # 1569 | 2014-01-09, 06:56 | Report

I remember memory leak in dbus-daemon which appeared some years ago which does not free memory for every dbus call. When I called some dbus function every 0.5s after 2 days dbus-daemon has eaten 200MB. Maybe this is fixed, but I do not trust dbus anymore and I will never use it for polling...

freemangordon | # 1570 | 2014-01-09, 07:08 | Report

Originally Posted by pali View Post

I remember memory leak in dbus-daemon which appeared some years ago which does not free memory for every dbus call. When I called some dbus function every 0.5s after 2 days dbus-daemon has eaten 200MB. Maybe this is fixed, but I do not trust dbus anymore and I will never use it for polling...

I am almost sure (it is a while since I looked in mafw sources for the last time) that there is a "position changed" callback (or similar dbus signal)

The Following User Says Thank You to freemangordon For This Useful Post:
Estel