search

radekp / qtmoko

QtExtended, formerly known as Qtopia from TrollTech, discontinued by Nokia
http://qtmoko.org
Other
70 stars 39 forks source link

QMplayer issues since v44 #124

Closed ivaylo-valkov closed 12 years ago

ivaylo-valkov commented 12 years ago

Version 44 of Qtmoko introduced some changes to QMplayer, but not all of them are useful and make the player kind of unusable. The following is a list of issues I've noticed. If necessary I'll put them in a separate bug reports.

It is no longer possible to move the program in the background by the side button, lock the screen and leave the FreeRunner in one's pocket. In the past doing this increased the battery life or at least it should, because the display switches off. Since version 44 moving the player in the background causes the music to stop.

The click to pause feature triggers from the tiniest move and/or touch, so the fabric of a pocket can turn the music off.

The slide to volume functionality seems to be very sensitive and the smallest drag turns the volume up/down.

When the player is back in the list of files mode, the labels "click to pause" and "slide to adjust volume" are visible above the list of files.

When the play button is pressed the video mode is such that only "click to" part of the text labels is visible.

Thanks.

radekp commented 12 years ago

Hi, all of these new bugs are caused by the feature which stops the player on incoming call. I think i will be fairly easy to fix them - e.g. by adding "lock" button when it starts playing music. I hope can get to it for qtmoko v46 or v47.

thanks for report, no need to make separate bugs for this issue

radekp commented 12 years ago

I have added now code to lock/unlock the screen (by sliding up) so it should not react on accidental click. The labels issue is also fixed. Code is commited and will be part of v46.

Thanks for reporting again

Radek

ivaylo-valkov commented 12 years ago

Great. Thanks!

ivaylo-valkov commented 11 years ago

Hi, I've tested the changes with v47. They are a great improvement, but it seems to me that there could be some more fixes.

For example, when the screen is locked the gestures for volume up/down and pause can still be performed.

When QMplayer enters playback mode the screen resolution is lower (higher?) and the guidance text for volume up/down and pause is not visible in full. [1]

When I try to increase the volume it always goes to the max, but I think this is a more general bug with sound at all, for which I will report a separate issue.

Is it possible to show the clock while in playback mode? This will be really convenient.

Thanks.

[1] http://e-valkov.org/qtmoko-bug-reports/qtmoko-qmplayer-resolution.jpg

radekp commented 11 years ago

For example, when the screen is locked the gestures for volume up/down and pause can still be performed.

This is intended behaviour - in fact it's not called "locked" but dimmed. The idea was to save the user from accidental touch. It's now very unlikely that you will slide half of the screen by accident (e.g. in your pocket).

When QMplayer enters playback mode the screen resolution is lower (higher?) and the guidance text for volume > up/down and pause is not visible in full. [1]

I believe that this isfixed in v48 (which is now building)

When I try to increase the volume it always goes to the max, but I think this is a more general bug with sound at > all, for which I will report a separate issue.

It works good on GTA04, i'll have to try on Freerunner - IIRC the volume control was much more sensitive there.

Is it possible to show the clock while in playback mode? This will be really convenient.

Since it can play also videos, it wont be that easy. We would have to find out somehow if mplayer is playing video or just audio - maybe checking in the /proc if mplayer has open framebuffer could work.

ivaylo-valkov commented 11 years ago

Thanks for the fast reply.

OK, dimmed it is. I just used the terminology you introduced in one of you comments. :) To be fare I haven't tested it yet in real world situation. It was just an assumption.

OK I'll test v48 or a custom build if I am able to successfully build.

I don't know if you are aware, but Mplayer supports a slave mode [1] which is intended for use with frontends. It also could accept commands over a FIFO file. I assume that the "get_video_bitrate" command will return zero/null for an audio file, so it should be enough to distinguish video/audio files. This interface could also be used to display media file metadata or duration and progress. Unfortunately right now I don't have the spare time to help with this.

Thank you for your work!

[1] http://www.mplayerhq.hu/DOCS/tech/slave.txt#

radekp commented 11 years ago

Ahh the slave mode looks cool - thanks a lot for the hint, i think this is exactly what we need.

ivaylo-valkov commented 11 years ago

I have some real-life experience with the dimming of the screen. Well it still has issues. Ofthen I find the device not dimmed in my pocket. The volume and pause/stop functionality is also triggered while the Freerener is kept insde a pocket. Not all the time, but maybe with 40/60 ratio of the time.