Active Topics
-
Camera phone competition March 2023 "Endless" (35)
to General by Maemish - 1 day, 17 hrs ago -
TLS 1.2 for N9 is ready (28)
to MeeGo / Harmattan by smartblu9 - 1 day, 18 hrs ago -
Maemo repository (3)
to Community by torsen - 2 days, 10 hrs ago -
Error after installing Leste on sdcard (11)
to Maemo 7 / Leste by Maemish - 3 days, 7 hrs ago -
Introducing ubiboot N9 (multiboot OS loader) (1,393)
to Alternatives by smatkovi - 4 days, 14 hrs ago - more...
| The Following User Says Thank You to Un27Pee For This Useful Post: | ||
|
2008-11-30
, 22:02
|
|
Posts: 62 |
Thanked: 13 times |
Joined on Aug 2008
|
#222
|
Originally Posted by pycage
I think every little bit helps. At least in my case, the media collection does not change that often, and I could use a few seconds of faster startup. Again I am only talking about this to be an option, and not the default behavior.
How long does this initial scanning take for your media collection? And how large is the collection?
It would be possible to store the index between sessions and only update it on demand.
Originally Posted by pycage
I agree , especially depending on what more is yet to come. However, these days I have found that there are many icons on the pull up that I hardly use, and at the same time, there are many frequently used ones, such as YouTube, that require two clicks.
I think the "pull up" panel would get quite cluttered with so many icons.
Originally Posted by pycage
How about a widget identical to the seek bar, right to the left of it ?
The reason why MediaBox doesn't have a software volume control is because it would take IMHO
unnecessary screen estate. What should the software volume control look like?
Originally Posted by pycage
My point was , the app scans on startup, and then scans again on going to the artist view. That looked odd to me. But maybe you are saving effort by delaying a potentially time consuming scan.
The artists list requires scanning the ID-tags of the audio files. This is more time-consuming
Originally Posted by pycage
Maybe you can have a special folder inside where all thumbnails are stored, and have a .jpg with the name of the artist with spaces substituted by dots or underscores. You can automatically pull from last.fm, or leave it on the user to supply their own pictures.
This would make sense. But I'm also wondering what would be a good way for supplying pictures.
There's no common standard for storing artists pictures.
Originally Posted by pycage
I think these two are related . First , about 'expanding' an album, the only 'problem' I have is that once I 'expand' , I cannot collapse, and it simply looks odd that I am merrily scrolling through a list of albums and all of a sudden, I am in the middle of scrolling through a list of tracks !
This was done to minimize the amount of clicks needed to switch between albums.
Can you explain this a bit more?
The second point was that - once I got to Track Info view, I have the main cover art in the center, and on the left I have a scroll list, where the cover art is duplicated for each track. That seems redundant. Every track in an album is going to have the same cover art, so I felt that you could use up some space to show more tracks instead of showing a picture.
Another approach could be - in the Track Info view, you do not show the tracks on the left at all ! Instead show the albums . In the middle you show the currently playing album's cover-art by default, but if someone taps on the screen ( you have empty space on both sides of the cover-art), it goes to a scroll list with all track names in that album. This can timeout and go back to the cover-art after no items have been clicked on that list for a set period of time. Now, to switch albums, or to navigate through tracks in the currently playing album, the user does not need to go anywhere at all. If they want to switch albums, they use the left scroll. If they want to see tracks in the current album, they simply tap on the center.
I do realize this does not solve the problem of viewing tracks without playing them. I am just thinking out loud here, so not every suggestion is quite elegant I admit.
The way it works now is okay as well - but would it be possible to wrap around the text in the scrolling boxes ?
Originally Posted by pycage
That is very generous of you and I am glad that I got in a lengthy wishlist without ticking you off
Usability feedback like yours is very important for me to push the UI in the right direction.
I am motivated to provide you feedback because you have been updating your application much more often than the other apps out there, and that is indeed commendable.
|
|
2008-12-01
, 00:07
|
|
Posts: 35 |
Thanked: 14 times |
Joined on Apr 2008
@ Paris, France
|
#223
|
Pycage, thanks a lot for your hard work !
I see 2 issues in rev 628 :
1- After I switch on and off the virtual keyboard (search in a list), kinetic scrolling becomes very slow.
2 – After listening to an internet radio, there's a weird sound remaining (shhhhhhh), even if I quit Mediabox. Only a reboot of the device can stop it
Last edited by Krazybat; 2008-12-01 at 00:10.
I see 2 issues in rev 628 :
1- After I switch on and off the virtual keyboard (search in a list), kinetic scrolling becomes very slow.
2 – After listening to an internet radio, there's a weird sound remaining (shhhhhhh), even if I quit Mediabox. Only a reboot of the device can stop it
Last edited by Krazybat; 2008-12-01 at 00:10.
 |
|
2008-12-01
, 08:04
|
|
Posts: 3,404 |
Thanked: 4,474 times |
Joined on Oct 2005
@ Germany
|
#224
|
Originally Posted by Krazybat
Yes, this is not the way it's going to stay. Somehow bringing up the virtual keyboard brakes the detection of pointer motion events in GTK. The workaround I found (not use gdk.POINTER_MOTION_HINT_MASK) however results in more jerky scrolling, so I have disabled it again (and use gdk.POINTER_MOTION_HINT_MASK again). For the virtual keyboard, another solution/workaround has to be found.
1- After I switch on and off the virtual keyboard (search in a list), kinetic scrolling becomes very slow.
Originally Posted by Krazybat
[/QUOTE]
2 – After listening to an internet radio, there's a weird sound remaining (shhhhhhh), even if I quit Mediabox. Only a reboot of the device can stop it
This sounds like the player backend did not shut down. I'll take a look.
| The Following User Says Thank You to pycage For This Useful Post: | ||
|
|
2008-12-01
, 08:34
|
|
Posts: 3,404 |
Thanked: 4,474 times |
Joined on Oct 2005
@ Germany
|
#225
|
Originally Posted by stl1859
Storing the index across sessions could help a bit. The quick initial scan could help detecting what needs to be updated, so that only those files are scanned again or dropped from the index.
I think every little bit helps. At least in my case, the media collection does not change that often, and I could use a few seconds of faster startup. Again I am only talking about this to be an option, and not the default behavior.
Originally Posted by stl1859
IMHO 2 clicks is just OK. 3 or more clicks would be bad. OK, it's a third click for Search/Featured/etc.
I agree , especially depending on what more is yet to come. However, these days I have found that there are many icons on the pull up that I hardly use, and at the same time, there are many frequently used ones, such as YouTube, that require two clicks.
Originally Posted by stl1859
The problem with this is space. It doesn't fit everywhere. A button to push bringing up a slider would work better I think.
How about a widget identical to the seek bar, right to the left of it ?
Originally Posted by stl1859
It's exactly because of this. Scanning the ID tags is more time consuming than just looking for files are there. But there's room for improvement.
My point was , the app scans on startup, and then scans again on going to the artist view. That looked odd to me. But maybe you are saving effort by delaying a potentially time consuming scan.
Originally Posted by stl1859
Yes, something like that. But I don't think it'll make it into 0.96.
Maybe you can have a special folder inside where all thumbnails are stored, and have a .jpg with the name of the artist with spaces substituted by dots or underscores. You can automatically pull from last.fm, or leave it on the user to supply their own pictures.
Originally Posted by stl1859
It's a good idea to have the left strip show the albums again (as it was in MediaBox <= 0.95).
Another approach could be - in the Track Info view, you do not show the tracks on the left at all ! Instead show the albums . In the middle you show the currently playing album's cover-art by default, but if someone taps on the screen ( you have empty space on both sides of the cover-art), it goes to a scroll list with all track names in that album. This can timeout and go back to the cover-art after no items have been clicked on that list for a set period of time. Now, to switch albums, or to navigate through tracks in the currently playing album, the user does not need to go anywhere at all. If they want to switch albums, they use the left scroll. If they want to see tracks in the current album, they simply tap on the center.
So to sum it up, the browser mode will stay as it is (I for one like it this way as you can quickly jump to another album with the N810 keyboard), the player mode will have the album thumbnails on the left and the tracks of the current album (much like it was in previous versions), and only when you go fullscreen, you'll get a big cover art with big prev/next/play/pause buttons (car-mode).
Would this all make sense?
Originally Posted by stl1859
But it helps finding the right direction step by step.
I do realize this does not solve the problem of viewing tracks without playing them. I am just thinking out loud here, so not every suggestion is quite elegant I admit.
Originally Posted by stl1859
You mean continually scrolling from right to left instead of right->left->right... ?
The way it works now is okay as well - but would it be possible to wrap around the text in the scrolling boxes ?
Originally Posted by stl1859
I'm always happy when people test the SVN version. This means that development takes longer because there are more bugs to fix and more things to implement, but in the end the result will be a lot better.
That is very generous of you and I am glad that I got in a lengthy wishlist without ticking you off
But I'm still aiming for a 0.96 release this year. Big changes won't happen for 0.96 anymore.
Now it's important to get the application API and plugin system clean so that people can start developing 3rd party plugins with 0.96.
|
|
2008-12-01
, 12:16
|
|
Posts: 20 |
Thanked: 0 times |
Joined on Aug 2008
@ Germany
|
#226
|
Wow, your activity is amazing!
It seems you work hard on the functions of picture browser as well.
switching between pics (in full-viewing mode) contains still a lot of "artificial distortion", but only during loading next pic. Is it possible to integrate a small "loading animation" because when loading larger pics it may take more than 5 seconds without knowing whether it acts ok.
Thanks a lot for your great encouragement!
mackaroni
It seems you work hard on the functions of picture browser as well.
switching between pics (in full-viewing mode) contains still a lot of "artificial distortion", but only during loading next pic. Is it possible to integrate a small "loading animation" because when loading larger pics it may take more than 5 seconds without knowing whether it acts ok.
Thanks a lot for your great encouragement!
mackaroni
|
|
2008-12-01
, 20:02
|
|
Posts: 62 |
Thanked: 13 times |
Joined on Aug 2008
|
#227
|
Originally Posted by pycage
Actually I noticed that every time I change the media folders, the app does a rescan. So if you had an option to turn off the initial scan, I would be perfectly happy to go do this every time I know something changed in some folder. Anyway, either ways this is fine. I do not consider this a big deal.
Storing the index across sessions could help a bit. The quick initial scan could help detecting what needs to be updated, so that only those files are scanned again or dropped from the index.
Originally Posted by pycage
I agree - it is not a big deal. Actually to be honest, I have a bigger problem with Canola on this one. In Canola it takes forever to get to the Cover Art view, even though I bet a majority of users want to go there right away.
IMHO 2 clicks is just OK. 3 or more clicks would be bad. OK, it's a third click for Search/Featured/etc.
Originally Posted by pycage
Agreed - but I was trying to come up with a solution that blends well with the existing UI. You are taking up the top right with the total/elapsed time display. If you could bring that down to the seek bar, then the corner can be used for the volume .
The problem with this is space. It doesn't fit everywhere. A button to push bringing up a slider would work better I think.
Originally Posted by pycage
I consider this low usage -so I wouldn't worry too much about it. Same goes with the artist thumbnails. I think you remember how kagu shows them . My ideas came from there.
It's exactly because of this. Scanning the ID tags is more time consuming than just looking for files are there. But there's room for improvement.
Originally Posted by pycage
Yes - I am not suggesting to change the browser mode. Actually with my proposal, the Track mode is all I would need, *most of the time* . I can go to the browser mode to browse tracks I do not want to play. I still like the current playing album cover art in the middle. What I am suggesting is that you have a toggle mechanism, where the middle can *temporarily* change to a track list, and go back to the cover art, once I am done browsing / picking tracks.
So to sum it up, the browser mode will stay as it is (I for one like it this way as you can quickly jump to another album with the N810 keyboard), the player mode will have the album thumbnails on the left and the tracks of the current album (much like it was in previous versions), and only when you go fullscreen, you'll get a big cover art with big prev/next/play/pause buttons (car-mode).
Would this all make sense?
Originally Posted by pycage
No i meant that sometimes the text in the scrolling boxes get cut off because they are too long. If we could show multiple lines in one scroll box then we could accommodate longer names etc.
You mean continually scrolling from right to left instead of right->left->right... ?
Originally Posted by pycage
I think you have made major improvement since the previous release - so it is definitely time for 0.96. I will look forward to it
But I'm still aiming for a 0.96 release this year. Big changes won't happen for 0.96 anymore.
|
|
2008-12-06
, 16:09
|
|
Posts: 462 |
Thanked: 550 times |
Joined on Sep 2008
@ Moscow
|
#228
|
Got new rev. 629
1. One thing made me confused from the start... New "Albums" in "Music" part... IMHO, it's to be splitted into 2: 1. FS hierarchy and 2. separate list ordered by albums info...
2. Still in images not all folders have a thumb meanwhile all the subitems in that folder do have thumbs...
3. Fullscreen viewing of images has quite strange behaviour.
1. One thing made me confused from the start... New "Albums" in "Music" part... IMHO, it's to be splitted into 2: 1. FS hierarchy and 2. separate list ordered by albums info...
2. Still in images not all folders have a thumb meanwhile all the subitems in that folder do have thumbs...
3. Fullscreen viewing of images has quite strange behaviour.
|
|
2008-12-07
, 14:35
|
|
Posts: 3,404 |
Thanked: 4,474 times |
Joined on Oct 2005
@ Germany
|
#229
|
Originally Posted by 412b
"Albums" is using the FS hierarchy where there are no ID tags available. The plain FS hierarchy is already accessible in the folder browser.
Got new rev. 629
1. One thing made me confused from the start... New "Albums" in "Music" part... IMHO, it's to be splitted into 2: 1. FS hierarchy and 2. separate list ordered by albums info...
Originally Posted by 412b
Thanks for reporting. I found the bug. Some caching went wrong.
2. Still in images not all folders have a thumb meanwhile all the subitems in that folder do have thumbs...
Originally Posted by 412b
What do you mean by that? Please tell me more.
3. Fullscreen viewing of images has quite strange behaviour.
| The Following User Says Thank You to pycage For This Useful Post: | ||
|
|
2008-12-07
, 16:14
|
|
Posts: 462 |
Thanked: 550 times |
Joined on Sep 2008
@ Moscow
|
#230
|
Originally Posted by pycage
Well, in previous revision FS it was more friendly to my mind and clear...
"Albums" is using the FS hierarchy where there are no ID tags available. The plain FS hierarchy is already accessible in the folder browser.
1. Adding items through folder browser is enormously long way (4+ clicks) with switching the view... It's a step backwards to previous 1-3 clicks...
2. I've got a really mind-blowing mixture in "Albums" because of the large amount of albums, folders etc...
3. Items w/o Album tag could be grouped in "No album" group, e.g.
So my main point is that separated FS and ID tags is more user friendly...
Originally Posted by pycage
When switching images in fullscreen, new image moves from left to right (and vice versa, may be just a visual effect) with distortion in horizontal direction then stops and looks normal. The strange thing is that left-to-right-and-back movement of the image...
What do you mean by that? Please tell me more.
 |
| Tags |
| media player, mediabox |
«
Previous Thread
|
Next Thread
»
|
All times are GMT. The time now is 03:50.
Well all my youtube videos stored on my device started working again, radio almost starts playing without buffering, navigating is snappier now its just almost perfect good nice job and the bonus of the themes to be included BIG Thanks
Uncle Pee
T3 - IT 810
Confidence is hard to gain easy to loose impossible to regain, Pee