[N85] Bug Report (collective)

Few of us over at N95Users.com have collated a list of bugs with the N85 which hopefully someone from Nokia will read on here and bare in mind for future software updates.
Common Bugs:
- camera picture noise in low light
- keypad does not light up during a conversation, restricting operation of device during a conversation in low light
- plugging wall charger into phone, it thinks its connected to a PC
- default number icon does not appear next to contacts in list
Product Code [0560506] Specific:
1a) auto USB connection type. USB connection type is selected automatically by the phone despite the choice menu popping up
1b) auto USB connection interfering with music player. Because of the above problem, you always have a type of connection active, even if you only want to charge your phone by USB cable, thus preventing access to the memory card from the phone, thus music player does not function.
Suggested Solution (1a, 1b) - give option to toggle auto connection

- N85 connected as "USB Mass storage" (Windows Vista PC, no Nokia suite installed), on Home screen open the multimedia slide and hit the "Play" key. A message "USB connection in progress" (don't know the exact message as I have a french version) appears and the audio player is stuck... I didn't find how to quit the application (it's still in background). Had to shutdown the phone.
- N85 connected as "USB Mass storage" (Windows Vista PC, no Nokia suite installed), in charge. If you turn the phone off, the PC tries to install a "Nokia USB ROM" driver and fails. The whole turn off/turn on procedure seems very strange when the phone is connected on USB port (several bips, screen "flashing").

Similar Messages

Bug Report: Feature Request/Bug Report Form

Re: Feature Request/Bug Report Form
https://www.adobe.com/cfusion/mmform/index.cfm?name=wishform
The Feature Request/Bug Report Form does not include a drop-down option for Creative Cloud.

Hi Stephen,
We are collecting feature requests as idea threads here on the forums versus using that form. If you believe you have discovered a bug with Creative Cloud please post about it here on the forums.
Thanks,
-Dave

Bug report, Beta 2.12 Standard Edition

Bug report: redundant, confusing, and apparently erroneous calls to
jdoPreClear
and jdoPostLoad. Note in output the null name in the third iteration.
Hi,
A lot of information being sent. Sorry, but I think you'll find it
helpful. I expected the exact same sequence of calls to jdoPreClear
and jdoPostLoad on the 2nd and third iteration. In fact, since,
retain values is true, and no changes are being made, I expected that
jdoPreClear and jdoPostLoad would not be called at all on the 2nd and
3rd iteration.
David Ezzio
Using 2.12 Beta, standard edition
Business method uses one PM. Configured to datastore transaction,
retainValues == true, non-TR == false, and non-TW == false.
The business methods open a transaction and leave it open.
The client calls commitTransaction() to close the open
transaction.
Two persistent objects, Widget and Box. Each implement
InstanceCallbacks and put out a message in jdoPreClear ("will be
made hollow") and in jdoPostLoad ("has been made persistent-clean").
The Widget has a reference to its Box. The number in parenthesis
is the sequence number obtained from the object ID.
Business methods implementation:
public ArrayList getWidgetsByName(String name)
Transaction trans = pm.currentTransaction();
if (!trans.isActive())
trans.begin();
Collection c = (Collection) widgetsByOneName.execute(name);
ArrayList aList = new ArrayList(c);
widgetsByOneName.close(c);
return aList;
public void commitTransaction()
Transaction trans = pm.currentTransaction();
if (trans.isActive())
trans.commit();
Output: from three loops that:
call findWidgetsByName("Maxi-Widget")
list the widgets returned
call commitTransaction()
finding Maxi-Widgets ...
Widget Maxi-Widget (650) has been made persistent-clean
Box Large (652) has been made persistent-clean
Widget Maxi-Widget (650): Box Large (652) at location Top Shelf
Widget Maxi-Widget (709) has been made persistent-clean
Box Large (710) has been made persistent-clean
Widget Maxi-Widget (709): Box Large (710) at location Middle Shelf
Widget Maxi-Widget (708) has been made persistent-clean
Box Large (713) has been made persistent-clean
Widget Maxi-Widget (708): Box Large (713) at location Top Shelf
Widget Maxi-Widget (700) has been made persistent-clean
Box Large (717) has been made persistent-clean
Widget Maxi-Widget (700): Box Large (717) at location Top Shelf
Widget Maxi-Widget (707) has been made persistent-clean
Box Large (716) has been made persistent-clean
Widget Maxi-Widget (707): Box Large (716) at location Top Shelf
Finding them again
finding Maxi-Widgets ...
Widget Maxi-Widget (650) will be made hollow
Widget Maxi-Widget (650): Box Large (652) at location Top Shelf
Widget Maxi-Widget (709) will be made hollow
Widget Maxi-Widget (709): Box Large (710) at location Middle Shelf
Widget Maxi-Widget (708) will be made hollow
Widget Maxi-Widget (708): Box Large (713) at location Top Shelf
Widget Maxi-Widget (700) will be made hollow
Widget Maxi-Widget (700): Box Large (717) at location Top Shelf
Widget Maxi-Widget (707) will be made hollow
Widget Maxi-Widget (707): Box Large (716) at location Top Shelf
Finding them yet again
finding Maxi-Widgets ...
Widget null (650) will be made hollow
Widget Maxi-Widget (650) has been made persistent-clean
Widget Maxi-Widget (650): Box Large (652) at location Top Shelf
Widget null (709) will be made hollow
Widget Maxi-Widget (709) has been made persistent-clean
Widget Maxi-Widget (709): Box Large (710) at location Middle Shelf
Widget null (708) will be made hollow
Widget Maxi-Widget (708) has been made persistent-clean
Widget Maxi-Widget (708): Box Large (713) at location Top Shelf
Widget null (700) will be made hollow
Widget Maxi-Widget (700) has been made persistent-clean
Widget Maxi-Widget (700): Box Large (717) at location Top Shelf
Widget null (707) will be made hollow
Widget Maxi-Widget (707) has been made persistent-clean
Widget Maxi-Widget (707): Box Large (716) at location Top Shelf
-- All done!

Due to better understanding on my part, and the fixes in Beta 2.2, the
issues raised in this thread are put to rest.
Abe White wrote:
>
We'll investigate further. Stay tuned...
"David Ezzio" <[email protected]> wrote in message
news:[email protected]..
Abe,
Actually, it doesn't make sense. The first iteration shows
jdoPostLoad is called just prior to using the fields of Widget and Box.
After the commit, the instances are not cleared. So far, so good.
In the second iteration, we see that jdoPreClear is called, but
jdoPostLoad is not called. Yet the values are there for use during the
call to Widget.toString() and Box.toString() within the iteration. How
did that happen?
On the third iteration, now the value of name is null, but last we
looked it was available in the second iteration. Other than that, I
agree that the third iteration looks ok, since it is being cleared and
loaded prior to use. But in the jdoPreClear, the values should be there
since the values were used in the previous iteration and are not cleared
at transaction commit due to retainValues == true.
David
Abe White wrote:
David --
I believe the behavior you are seeing to be correct. Section 5.6.1 of
the
JDO spec outlines the behavior of persistent-nontransactional instancesused
with data store transactions. As you can see, persistentnon-transactional
instances are cleared when they enter a transaction; thus the calls to
jdoPreClear. When the default fetch group is loaded again (like whenyou
access the name of the widget) a call to jdoPostLoad is made.
You are seeing the name of one instance as 'null' in the third iterationof
your loop because the instance has been cleared in the second iteration,and
the jdoPreClear method is not modified by the enhancer (see section10.3).
Make sense?

Speedgrade bug reporting...

Just a quick query for the Speedgrade devs- do you guys collect bug reports from the Adobe improvement program reports? I'm seeing a lot of crashes when editing Cineform footage, but only when Speedgrade exits. Speedgrade itself can be quite crashy, and sadly I lack the time to try and report them all. If you guys are grabbing data from the improvement program then that'll save a lot of hassle.

Hi,
Adobe SpeedGrade is participating at the improvement program. Find a list of all participating products here: http://www.adobe.com/special/apip/improvement.html
If you encounter a crash, I would recommend to also post a report to the forums. Probably a faster way to find a workaround/solution for the problem.
What system are you using (OS, graphics etc.) ?
SpeedGrade version ?
I would like to take a look at crashlogs and SpeedGrade logs. Sent you a PM with further instructions.
Dennis

Is there a place to submit bug reports for iTunes 11?

I was wondering if anyone knows of any communities, or ways in which we can submit errors, or bug reports for the new version of iTunes, version 11.0? The 2 issues so far that I am seeing, is:
1. My account information: iTunes shows I have hidden purchases, when on all my iDevices, I have 0. (In fact, before the update, I un-hid all previously hidden purchases, and it showed correctly).
2. When syncing a device, on the last tab for items on device, on my iPhone 4, iOS 6.0.1, it shows I have 2 songs downloaded from my collection, when I know I have 0. (Verified by checking Settings>General>About>Songs = 0

Yes,
In iTunes;
Help (pulldown)
"Provide iTunes Feedback"
However, as of this writing iTunes 11 isn't listed in the 'Version list, so make sure that you state the version in your description.
-Alan
ps. If you dont see the Help pull-downmenu, press 'Alt' to toggle it.

Submitting bug reports for linux player

hello,
we're in the process of improving the
feedback
form to better collect your input on the linux version of flash
player 9. while we are waiting for these form updates to be made,
please use the "Problem description" field near the top of the form
to provide additional information such as:
* distribution and version
* browser and version
* any mutant library configuration (other than those included
with distribution)
* camera/microphone type (if applicable)
this information will greatly help our QE team in reviewing
and reproducing your issues, which leads to issues getting fixed
faster.
thanks!
jennifer
(adobe's flash player program manager)

Anyone have any idea how to submit a bug report for Oracle XE.Posting bug description in this Forum should be enough.

Face Tagging bug report

Bug report: when using the Face Tagging function if the collection of images to search includes images that are too large ('File size is too large' icon), Elements crashes.

Fred,
Thanks for posting that its good to share such discoveries. You could also send the bug report directly to Adobe, since they dont guarantee to pay attention to these forums (though there are a number of employees or contractors who do post here frequently without attribution). See the link at the bottom of this page:
http://www.adobe.com/support/photoshopelements/

Bug report follow-up

is there a way to follow-up on a bug report that i submitted? i have the bug number, but would like to see if the report was understood, filled out properly and determine the status of the bug report.
thanks,
doug

They comment on bugs if actions were taken. Otherwise - don't expect any feedback.

Solaris8 and 9 (possibly 7) /dev/poll driver bug report.

Hello,
I'd like to report a bug in the solaris 8 and 9 /dev/poll driver (poll(7d)).
As i do not have a support account with sun or anything like that, there
seems to be no other way to do that here (which is of course a very sad
thing).
Bug details:
The /dev/poll device provides an ioctl-request (DP_ISPOLLED) for checking
if a particular filedescriptor is currently in the set of monitored
filedescriptors for that particular /dev/poll fd set (open /dev/poll fd).
A quote from the documentation of the poll(7d) manual page taken from
Solaris9:
"DP_ISPOLLED ioctl allows you to query if a file descriptor is already in
the monitored set represented by fd. The fd field of the pollfd structure
indicates the file descriptor of interest. The DP_ISPOLLED ioctl returns 1
if the file descriptor is in the set. The events field contains the
currently polled events. The revents field contains 0. The ioctl returns 0
if the file descriptor is not in the set. The pollfd structure pointed by
pfd is not modified. The ioctl returns a -1 if the call fails."
It says that when you query for an filedescriptor which is currently being
monitored in the set, that it would return 1, and change the events field of
the pollfd structure to the events it's currently monitoring that fd for.
The revents field would be set to zero.
However the only thing which actually happens here, is that FD_ISPOLLED
returns 1 when the fd is in the set and 0 if not. When the fd is in the
set, when FD_ISPOLLED returns 1, the events field remains unmodified, but
the revents field gets changed.
A small sample code to illustrate:
#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <sys/devpoll.h>
main() {
struct pollfd a;
int dp_fd = open("/dev/poll", O_WRONLY);
a.fd = 0; /* stdin */
a.events = POLLIN; /* we monitor for readability, POLLIN=1 */
a.revents = 0;
write(dp_fd, &a, sizeof(a));
a.fd = 0;
a.events = 34; /* filled in with bogus number to show malfunctioning */
a.revents = 0;
printf("DP_ISPOLLED returns: %d\n", ioctl(dp_fd, DP_ISPOLLED, &a));
printf("a.fd=%d, a.events=%hd, a.revents=%hd\n", a.fd, a.events,
a.revents);
According to the documentation of /dev/poll and namely DP_ISPOLLED this
program is supposed to print the following:
DP_ISPOLLED returns: 1
a.fd=0, a.events=1, a.revents=0
However it prints the following:
DP_ISPOLLED returns: 1
a.fd=0, a.events=34, a.revents=1
You can take any number instead of '34' and it will simply remain untouched
after the DP_ISPOLLED ioctl-request.
I hope it's clear now that the solaris8 and solaris9 (and probably solaris7
with /dev/poll patch too) DP_ISPOLLED implementation is broken.
This bug is also easily illustrated by looking at the solaris8 kernel sourcecode:
<snippet osnet_volume/usr/src/uts/common/io/devpoll.c:dpioctl()>
case DP_ISPOLLED:
pollfd_t pollfd;
polldat_t *pdp;
if (pollfd.fd < 0) {
mutex_exit(&pcp->pc_lock);
break;
pdp = pcache_lookup_fd(pcp, pollfd.fd);
if ((pdp != NULL) && (pdp->pd_fd == pollfd.fd) &&
(pdp->pd_fp != NULL)) {
pollfd.revents = pdp->pd_events;
if (copyout(&pollfd, (caddr_t)arg,
sizeof(pollfd_t))) {
mutex_exit(&pcp->pc_lock);
DP_REFRELE(dpep);
return (set_errno(EFAULT));
*rvalp = 1;
</snippet>
its' clearly visible that the code writes the current monitored events to
the revents field:
'pollfd.revents = pdp->pd_events;'
and that it doesnt set revents to zero.
It's funny to see that this has been like this since Solaris8 (possibly 7). That means nobody ever used DP_ISPOLLED that way or people were simply to lazy to file a bug report.
Another funny thing related to this. is that Hewlett-Packard did seem to know about this. Since HP-UX11i version 1.6 they also support /dev/poll. From their manual page i ll quote some sentences from their WARNING session:
"The ioctl(DP_ISPOLLED) system call also returns its result in the revents member of the pollfd structure, in order to be compatible with the implementation of the /dev/poll driver by some other vendors."
Hopefully this will get fixed.
I also like to reexpress my very negative feelings towards the fact that you're not able to file bug reports when you do not have a support contract. Ridiculous.
Thanks,
bighawk

Have I mentioned how much i love my playbook now Great job on os 2.0

Did you know that Google toolbar doesn't work properly in FF rc1? I have filed a bug report to Google about this

The Google toolbar doesn't recognize a left mouse click when selecting a 'suggestion'. It's OK using the keyboard, however. I have filed a bug report with Google, but as this is an important extension thought you should know.

See also: http://forums.adobe.com/message/4662367#4662367
-Noel

Bug Report: The keyboard focus doesn't automatical...

Bug Report: When a conversation window opens, the focus doesn't automatically land in the chat entry text field.
Since the new interface for Skype was introduced officially in Skype 7.0, there is a bug with the system/keyboard focus for a new conversation window. When Skype is in "Split Window View" and each new conversation automatically pops up in a separate window, the system/keyboard focus doesn't land in the chat entry edit field. Instead, the user has to press Shift+TAB a couple of times, to move it there and reply to the chat message received. This especially problematic for screen reader users, who rely on keyboard navigation. This mainly occurs when a new conversation is started with an incoming message, but it sometimes occurs when moving the focus out of that conversation window and later back in it again (while it is still opened).
Steps to reproduce it:
1. From "View" menu, activate the "Split Window View", if it is not already enabled.
2. From Tools -> Options -> IM & SMS -> IM settings, enable "Open a new window when I receive a new message in Split Window View", if it is not already enabled.
3. From Tools -> Options -> Advanced, activate "Enable accessible mode", if it is not already enabled.
4. Activate the "Save" button, to save the changes.
5. Close all windows, related to Skype. You may keep only the main window opened.
6. Tell someone to send you a chat message. When the message arrives, Move the system focus to the conversation window in question, preferably with Alt+TAB. The system/keyboard will not land in the chat entry edit field as it did in Skype 6.21 and earlier and as it should by default, but in some unknown place in the window.
7. Move the system/keyboard focus in the chat entry edit field and keep it there.
8. Switch to another window, preferably from another application.
9. With Alt+TAB, switch back to the window of the opened Skype conversation. There is a chance that the system/keyboard focus will not land in the chat entry edit field as it did in Skype 6.21 and earlier and as it should do by default, but again in some unknown place in the conversation window. But that is harder to reproduce.
Test environment:
- Operating system: Windows 8.1 Pro N, 64-bit, in Bulgarian with all locale settings set to "Bulgarian".
- Skype version: 7.0.0.102 for Desktop.

This is a known problem, but Skype have not given us an estimated time for a fix.
Traditionally, Skype updates have been roughly monthly, so we are due a new version sometime soon. Many of us here are hoping that is has a bunch of fixes for the UI, the focus problem being one of them.
Sean Ellis - uses Skype chat for serious work
Click here to read my blog post on Skype 7 and basic principles of GUI design

Bug report: Naming a Bin after creating it with drag'n'drop

There seems to be a small bug when giving a newly created bin a name after creating it by drag'n'drop of several clips onto the "New Bin" icon.
To reproduce:
Select some clips in your project browser
Drag them onto the New Bin button
A new bin is created with the clips in it
- the bin name for it appears to be selected, and editable - just as if you had created a new empty bin by clicking the New Bin button
- type in a new name - it accepts the name fine, now press enter.
- your new name disappears, and *now* you are really in the mode to edit the bin name
- type your name again, and it works.
Work around:
When creating new bins by using drag'n'drop of clips onto the New Bin button, first press enter once to enter into the proper edit mode before giving the bin a new name.
(is there a better place to file bug reports?)
Version 6.0.1 (014 (MC: 264587))
Hardware Overview:
Model Name:          Mac Pro
Model Identifier:          MacPro5,1
Processor Name:          Quad-Core Intel Xeon
Processor Speed:          2.8 GHz
Number Of Processors:          1
Total Number Of Cores:          4
L2 Cache (per core):          256 KB
L3 Cache:          8 MB
Memory:          8 GB
Processor Interconnect Speed:          4.8 GT/s
Boot ROM Version:          MP51.007F.B03
SMC Version (system):          1.39f11
SMC Version (processor tray):          1.39f11
OS X 10.6.8

Er, just answered my question about bug reports by reading the "read this before posting" link above
But I'll leave this here for the work-around in case anyone else needs it.

Bug report: 3.2; DAC; GridControl; Navigation - Invalid reaction to mouse drag

Hi,
This is a bug report, I think.
I have a one-column GridControl with mandatory column. Normally, DAC framework prohibits from navigation out of empty field and emits one of those DAC-1002 or DAC-603 errors. The only exception I noticed was a double-click on another row. In this case navigation allowed but an error is still produced.
Today I was playing with this GridControl and discovered that I can drag the yellow frame across rows. And here comes a bug - GridControl doesn't change the current row on InfoBus according to current selection marked by yellow frame.
In my case it brings the following problem: if the cursor is placed on the new empty row, user drags the cursor to another row and then tries to use any other navigation means except dragging, he gets a navigation error. DAC framework still thinks that the current row is the empty one and produces an error telling that the attribute cannot be empty.
Dev Team, any comments?
Regards,
Vladimir

Hmm... Nobody answers. I'll try another variation of the same question.
DAC framework implicitly validates attributes on the base of Mandatory constraint in the Entity Object definition. Is it possible to set the level of this validation? For example, I want to conduct validation only when user navigates out of the row or the whole rowset, but not when he just leaves a field.
Regards,
Vladimir

Bug report: vpn (ipsec) interface number in snmp always change

Hi,
this is a bug report for RV082 hardware version 3 and 4, firmware version 1.x, 2.x and 4.x (all latest versions). I hope someone from cisco/belkin reads it.
Summary:
The snmp interface number of a VPN Tunnel change when the VPN tunnel disconnect and then re-connects.
What should happend:
The VPN Tunnel number 1, should always have the same snmp interface number. In RV082 v4, this number should always be 10. For example, the LAN, WAN1 and WAN2 always have the same snmp interface number.
What is the problem:
The VPN Tunnel number 1 change the snmp interface number, from 10, to 11, to 12, etc.
How to reproduce:
create a VPN Tunnel using 2 RV082 or 1 RV082 and 1 RV042. Once the VPN Tunnel is connected write down the snmp interface number. A few days later, disconnect the cable of block internet access. Then restore the internet conection and write down the snmp interface number, you should note that the snmp interface number have changed.
Tools used:
PRTG Network Monitor
Please take a look at the attached image, note all the "ppp" interfaces, theres only 1 VPN Tunnel (gateway-to-gateway) defined.

Hi Tom,
many thanks for your reply.
I see that I have to call Tech-support, in order to report a very technical situation, explaining them this is a bug report and I want them to make a better product.
Since I won't pay a dime for this problem to be fixed, I can only see pain in this path(calling to speak with a tech support representative).
I also readed that Belkin has bought Linksys, so I don't know if the RV082 will remain with Cisco or will go with Belkin.
So, my only hope is to document this bug, that is pressent inall firmware version and hardware version of the RV082 as of today.
many thanks for your help,
regards,
Oliver

Bug Report: Shortcuts for Adjustments in 3.1

I have verified that bug with a brand new test account (Aperture 3.1 and OS 10.6.4 with latest Pro Update):
- Make an adjustment to an NEF-file
- save that adjustment as a preset
- assign a keyboard shortcut to that specific adjustment
Switch to the next NEF-file and make your usual adjustments:
- initiate that shortcut to apply the already saved preset/adjustment
All of a sudden, all already applied adjustments are set back to defaults!!!!
To sum up:
Shortcuts are presently not useable!
Bug Report was filed!
Any observations???

I got it myself. My shortcut combination contained the option key. That causes AP to replace any adjustments already made to the image. You have to use a keyboard short cut combination without the option key.
The question is, why AP 3.1 is not smart enough to refuse such a combination??? In version 3.0.x everything worked fine!!!

[N85] Bug Report (collective)

Similar Messages

Maybe you are looking for