Re: PR 1.3 bugs
 

That's like asking Nintendo to fix the Wii because it can't connect WPA2 to a router running dd-wrt but it works everywhere else...

I think Cisco is the one that should fix it, and they won't care. Why? Because in this world there are more Nokia phones out there than all the iPhones, Androids and Blackberry together, that means Cisco is at fault.

Just configure WPA + WPA2 in the router and the N900 will connect WPA just fine.

Re: PR 1.3 bugs
 

Reflash the eMMC that should fix the problem...at least it worked for me. But after that i'm having a problem with my call, the phone puts the calls on hold on its own. This happens like every 3 mins, each time i activate the call again and after a lil bit it puts itself on hold again.

Re: PR 1.3 bugs
 

I have 2 problems so far... would like to know your opinions on them before I open a bug report so they can be fixed in PR 1.6 :D

RSS Feed Reader Applet
The applet has a refresh-button for doing manual updates. RSS feed reader is set to automatically refresh only via WiFi. When I'm on 3G and press the refresh button on the applet, it changes back from the red X to the normal refresh-symbol in less than a second and does nothing. Sometimes, it remains a red X and - well, doesn't do anything, either.
In PR 1.2, it used to update all feeds as epected and then change from x to the refresh-symbol again.
Seems to happen on 2G/3G only, not on WiFi.

Media Player - Videos not sorted properly
I have my videos sorted by date in the media player. Before PR 1.3, I had the oldest video at the bottom of the list and the most recent on top.
Now, this sorting only works as expected for videos that were added to the device after the firmware upgrade. All other videos are sorted in a way I cannot make sense of... it's certainly not by date, it's not by name either. It seems to be random, but it's the same each time I open the video browser.
I tried "tracker-processes -r" (can't recall where I got that from) and rebooted, hoping that would rebuild the database... no effect at all.

Can some of you check if you see similar effects? Or do you have ideas what could cause this?

Re: PR 1.3 bugs
 

Thanks, At My Office i cannot Chang an Access Point Configuration Coz A Policy not allow to use WPA. :(

Re: PR 1.3 bugs
 

depending on the actual configuration your office uses (WPA2 can be a lot of different things), if it's something like EAP / MSCHAPv2, maybe this bug report or this wiki page are of relevance to you.

Re: PR 1.3 bugs
 

Can confirm the Media player issue - all my old files are not sorted according date. Newer files are sorted according to copy date/time.

Re: PR 1.3 bugs
 

don't know if this is a bug, but whenever i go online (i set my settings to 'always ask' for a connection) it always says 'no connections saved'. it is seriously annoying, as i have already saved a number of connections.

i have reinstalled my firmware via Nokia Software Updater and did not restore my back up thinking that my back up might be the one causing the problem. but after setting up my files one by one, the problem is still there. i even deleted all of my connections and set it up all over again. the problem still remains. is anyone else experiencing this? found any way to overcome this?

Re: PR 1.3 bugs
 

bug when media player start music after phone call is still there,

Re: PR 1.3 bugs
 

same here, had this since 1.2 though

Re: PR 1.3 bugs
 

That will not fix sorting.

Close media player, images, etc
Open terminal.

tracker-process --hard-reset

Give it a second
Open Images. This should trigger reindex.
Leave it be a while, until CPU dies down.

Re: PR 1.3 bugs
 

-r is --hard-reset, so they'll both do exactly the same thing.

Re: PR 1.3 bugs
 

Yeah mine is also working alright.

Re: PR 1.3 bugs
 

Oops, I thought -r was restart.

Hmm, it could be that the old videos were touched, so they are all older than the ones you added. Try a ls sorted by date?

Also, did you see it rebuild? After a reset, the images are blank and they regain thumbs as tracker goes on.

Re: PR 1.3 bugs
 

Done this, and the files are still NOT organised.

Re: PR 1.3 bugs
 

Yep did see a rebuild (over 2 minutes)

Did
A) ls -c
B) ls -t
C) ls - u

Don't see any order.
Looks random.

----
-c With -l: sort by ctime
-t With -l: sort by modification time
-u With -l: sort by access time

Re: PR 1.3 bugs
 

did the hard reset trick a 2nd time. it changed the order once again (new files that i added after pr 1.3 update are now mixed with the old ones), but i still cannot see a pattern. it's a little difficult for me because my video files are not all in one folder.... it seems, though, that there's a tendency that files that are in one directory appear closer together in the thumbnail list. need to check this further.

it becomes annoying, though.

btw: first time i did the tracke reset, i was root. now i wasn't. it seems to clear different databases depending on if you're root or not. which is the correct way? root or user?

Re: PR 1.3 bugs
 

user

nicolai

Re: PR 1.3 bugs
 

same for me :(

before pr 1.3 update it's worked!

from terminal:

some idea?
???

Re: PR 1.3 bugs
 

OK, I'm pretty sure I found out what happens in Media Player, but I need confirmation from someone who's familiar with the Ontologies tracker uses:

When you examine a file with
you get some info about the file, including time stamps for
File:Modified
File:Accessed
File:Added

I would have expected videos to be sorted by "File:Modified". They are not. For the files I checked now, they're all sorted by "File:Added"... which happens to be the date when I re-created the index.

So what I think happens is that tracker indexes all files properly, but the Media Player sorts them according to when they were added to the database, not when they where created or modified. Maybe this is even an old bug but I didn't notice when I had fewer files on the device. If you don't rebuild the database, you won't notice, will you?

So my question is:
Is "File:Added" meant to hold the time when the file was last indexed? In other words: Is tracker wrong in writing the date or is Media Player wrong in using it for sorting?

Re: PR 1.3 bugs
 

I'd expect File:Added to be the date tracker added it to the index, so I'd say Media Player is wrong. I'd use File:Created instead for an initial creation date. According to the docs I can find (http://www.freedesktop.org/wiki/Spec...ns/config-spec), File:Added is not a standard piece of metadata, so I'm not sure it's well defined though.

Re: PR 1.3 bugs
 

can you elaborate on why it stopped eating up cpu/battery? has it reoccured?

my calendar keeps running on 100 percent no matter what i do. before 1.3 this problem was easy to fix, but now nothing I can think of helps. I did a complete re-sync, deleted the old calendardb, deleted the old calendar, tried nuevasync and direct syncing with gmail - calendar keeps going crazy after each sync.

anyone got any idea what do do?

Re: PR 1.3 bugs
 

Check to see what file:added says against the date/time of the file in question. If it's close to created, modified, or present.

I'm going to guess that file:added is close to present, and close together for all unsorted files?

I am going to raise one point, though. I added an old file to the card and the images app inserted it at the very top (it was old). Moving a file off the device and returning it also inserts it in the timeline. So I'm guessing it works. Since tracker indexes both images and media, it's probably not a tracker issue?

Re: PR 1.3 bugs
 

FWIW, Feeding it works normally with my ipv6 test connection, which probably it works ok with the normal 3g connection as well.

I don't know why anyone uses the standard RSS program; Feedingit is one of my mainstays.

I never sort video, so I don't know whether it works normally for me.

Re: PR 1.3 bugs
 

This was posted by me in another thread an by someone else as well, I would just like to get it on this main thread,

FreOffice and DropN900 both crash on PR1.3 for me with a stack trace in QtCore.

Anybody not seeing this?

Re: PR 1.3 bugs
 

As I said: Yes, for the files I checked (too many to check all now), File:Added was today around noon - when I re-built the index. Most of the files I checked were created during my summer holidays.

My photos are all sorted correctly. No problem there. Only video files are amess.

BTW, I wonder... when you install OGG support, does the package force the tracker index to be re-built? I thought about it because I wondered why all of a sudden File:Added dates should have become changed after PR 1.3. - The only explanation I have is: After PR 1.3 I no longer had access to my OGG Vorbis files. I uninstalled and re-installed OGG Support (which cured this issue), but I hadn't looked into the video section of media player before. Maybe everything was OK there right after the update (because usually File:Modified and File:Added are close to each other) and only OGG Support re-building the index caused the issue?
In this case, it wouldn't be related to PR 1.3 at all (or only indirectly).

Re: PR 1.3 bugs
 

If index rebuilding destroys sorting I think it qualifies as a bug. Indexing is a way to speed up the process not to lower functionality.

Well, there is a way. Move all files off the device, restart tracker-process. Then, re-add files one by one. they will be readded to the tracker as they are created.

Not easy, but if you suffer from OCD, it's a way out. And, you need to transfer via wifi or something. While in USB mode, tracker is suspended for obvious reasons.

Alternately, rename the video folder to Video2, tell tracker-cfg to not index Video2 and move them in the order of creation. Should be doable with a script.

ETA: If it is as you say, it's not a PR 1.3 bug, since it's always worked like that. I remember 1.2 also reorganizing my video files. I just never cared, since I had 5 then.

Re: PR 1.3 bugs
 

I must be suffering from OCD, because on my way home I thought about doing just that: Creating a script that'd add the files to the index one by one in the same order that they were originally created. Sick, isn't it? I should better do something about my mental health rather than solve the media player problem. :D

Re: PR 1.3 bugs
 

I always thought it didn't have a desktop applet?

Re: PR 1.3 bugs
 

Ever since installing pr1.3 (installed global release on a UK mobile, if that makes any difference), I get browserd process hogging the CPU at 97% to 99% AFTER using and closing down the maemo browser.
I have to kill -9 the browserd process to stop it. Then it restarts by itself again, but it's not hogging the CPU any longer... until I open, use, and close the maemo browser again.

Any ideas what might be causing this and how to fix it??

Re: PR 1.3 bugs
 

Don't think it's 1.3. I had that browserd thing in 1.1.

I have little clue as to the fix, I think I cleared all cache, cookies, etc and that fixed it. Or was it PR 1.2? In any case, it's always been there. Wait, or did it happen when using dictionary input in MicroB?

I know this isn't any help, but at least you aren't looking at a 1.3 specific, methinks. Search the forums, I definitely remember doing that.

Re: PR 1.3 bugs
 

I've been having the "Saved Connections" dialog box popup, when I already have an active data connection. It does this 9 times roughly, before it's dismissed and doesn't come up.

Re: PR 1.3 bugs
 

Feedingit does, unless I don't understand what a desktop applet is :)

It even has a widget, but I don't like the widget. Too space-consuming.

Re: PR 1.3 bugs
 

Anyone else experiencing Hildon freeze in the PR 1.3. UI It has now probably 4 times totally stopped working... I can power off phone from power off button, phone responses to locking device also if i plug in charger the sound come and it apperiantly starts to charge phone, but nothing happen at the screen. So it then some hildon bug?

Or something that is related to my actions :D

Re: PR 1.3 bugs
 

Nobody but you has mentioned this problem, that I've seen. How did you do the update? Did it seem to go smoothly?

Re: PR 1.3 bugs
 

Yeah it went smoothly....Phone works quite nicely, well i have to dig into this some more and see when it actually does this.

First time today was when i was checking-in for foursquare venue via barriosquare and second when i was messing around in filebox...

I have OC`ed my phone, so if this continues i do something to that.

Oh also i have custom one colum hildon form Mohammed AG :)

Re: PR 1.3 bugs
 

Am I the only one who cant open "sharing accounts" in the settings?
In applications I can use or configure the sharing-manager.
Detected this possible bug after installing pixelpipe service.
Can someone confirm?

Re: PR 1.3 bugs
 

OK, checked it now... it only shows the name of the feed, not the headlines. That's not what I need. I want the headlines on my desktop. I hardly ever open the feed reader as such. But thanks.

Re: PR 1.3 bugs
 

Hmmm I never had this problem before, not in pr1.1, not in pr1.2 either!
I don't know about using dictionary input... you mean in website text fields etc.? I've always used whatever was there, most of the time I don't get dictionary input showing anyway.
I'll clear cache, cookies etc and see if that does it, and I'll try to have a look through older posts.

Re: PR 1.3 bugs
 

my love, dont expect a pr1.4

Re: PR 1.3 bugs
 

I seem to have fixed the problem of losing all Contact entries (from Exchange ActiveSync and Voip/IM accounts) after reboots that I described in this post.

The fix was simply to backup my device, reflash it, including the eMMC via these instructions.

Upon re-starting the device, I then used the built-in Restore feature to restore Bookmakrs, Settings, and Application List. I made sure NOT to backup or restore Communications and Calendar, since that was the data store that seemed buggy.

All my Contact entries re-appeared after the first sync with Exchange ActiveSync (to Hotmail). I've rebooted several times, and all Contact entries are preserved.

Hope this helps someone.