Another XAV-72BT BUG

I've checked the format of the JPG files that don't display when playing the MP3 files in the same folder. None of them use the progressive JPG format. And these same JPG files do display if I select 'Images' instead of 'Audio' from the XAV72bt user interface. This appears to be a software bug to me. I'd very much appreciate it the appropriate support team would take a look at this.

I've discovered another design problem withthis unit. I recently ripped a video from a music DVD to an MPEG4 file. The format of the file is well within the limits given in the user's manual but this head unit will not play it I read the disclaimer in the user's guide indicating that there is no guarentee that a file can be played even if it is within the limits given.
The real problem is with the USB menu. The USB drive contains many audio files and this one video. From the menu I selected video and the unit quickly responded with "no playable media found". The problem is that there is no immediate recovery for using this USB. There is no way to go back and select for audio files. No user menu options appear. If I unplug the USB and plug it back in, nothing is changed. The unit recognizes that a USB device has been reconnected but it remains in video mode. I can probably take the USB back to my computer and delete the video file but that seems to be a poor solution. This is yet another example of how this unit seems to have gotten to the market before it was ready. See my other posts in this forum.

Similar Messages

  • XAV-72BT Comments

    I had two main reasons for replacing the head unit in my car; I wanted the RDS data and I wanted bluetooth connectivity for handsfree calling. I've purchased lots of Sony products in the past and I've always been happy with them. My main and secondary TV's are both Sony. I have a Sony DVD player and VCR (yea - I know - 'what's a VCR?') Late last year I bought a Sony digital camera - DSC-HX100V. They all seem well-designed and reliable. I'd read some of the complaints on-line about the XAV-72BT and some of the favorable reviews. I thought - 'how bad could it be? it's a Sony'.
    I bought the XAV-72BT and installed it in my car. A lot of the features are well designed and work well. But a number of things have me asking; 'what were they thinking when they came up with that?'
    I have a number of questions for the designers/software developers of this unit:
    The RDS data is limited to 8 characters at a time. So getting the entire song title and artist can take quite a while. The driver has to keep glancing back at the display to avoid missing a piece of the data. This could certainly be called a distraction to the driver. There's an abundance of screen space; why limit the RDS data to 8
    characters? Think about how many words in song titles or artist names are more than 8 characters. The preset display for each band includes space on each preset button for the frequency and 8 characters of RDS data. That data is updated on the currently selected station if it is one of the presets. But not on the other preset buttons. Perhaps this is why the RDS data on the main screen is limited to 8 characters. But what is the point of having
    stale 8 character fragments of RDS data on the preset buttons?
    The RDS data on the main display is covered by the preset buttons display. I guess this design choice was made because the RDS data for the active station is displayed on the preset button. But it's not as easy to read there as on the main display. Maybe that's why they made it green on the preset button. Green? Really.
    The display includes an attenuate button ('ATT') when the preset buttons are displayed. The buttons can be removed from the tuner display by touching the screen at a non-button location and gestures can then be used to change between presets or to tune to the next station on the dial. But the 'ATT' button is also removed. This seems wrong too. It takes a few seconds for the preset buttons and the ATT button to reappear when the screen is tapped. This negates the convenience of the ATT button.
    The user can also use a PTY button to tune to another station that broadcasts program material from a list of types. Interestingly, when using this mode the buttons are removed from the screen automatically after a few seconds. Why isn't this kind of option available when using the preset buttons?
    There are two available 'visualizer' selections (wow - two!). I thought that visualizers responded to the audio being played. If these two do that I can't detect it.
    When an audio CD is being played a cheesy musical note graphic appears on the right side of the screen. I suppose it seemed appropriate to put something there but if several options couldn't be available, the user should at least be able to turn this off.
    Several years ago I purchased and installed a Kenwood single DIN unit for a different vehicle. The display was monochrome and of course much smaller. But it had quite a bit of flexibility in selecting what to display and where to display it. It had a simililar motorized panel to provide access to the CD and unfortunately the electro-
    mechanical design was poor. It failed on its own (not through abuse or misuse). I had it fixed and not long after it failed again.
    The sound from the XAV-72BT is terrific. The audio setup options are very good. My car had an OEM unit from Alpine but I was surprised how much better the Sony sounds. The handsfree functionality via bluetooth is great. I'm satisfied with the setup and usability.
    The touchscreen response is a bit inconsistent and can be frustrating. I suppose I may buy the optional remote to avoid some of that (this is kind of a surrender I guess). I don't have an iPod and don't plan to get one so I can't comment on some of the complaints I've read about the slowness of the interface.
    I think Sony could do a lot to improve this unit. Shame on them for releasing a product with obvious flaws like these. If the firmware in this unit cannot be upgraded by the user then shame on Sony again for not including this capability.
    I'm kind of a minimalist. My vehicle has other LCD driver displays. At the very least I'd like to be able to select the background color to match the other displays (this means NOT from a limited list of colors).
    This unit has a large screen. It just seems to me that the designers had no imagination when it came to providing the user with a
    lot of flexibility in how that screen space should be used when listening to the tuner.
    All in all I'm pretty disappointed with this unit. I'm even more disappointed that there is no indication that Sony has any intention to respond to the user complaints.
    Bear Deleware

    Thank you for your post and comments - I'm sorry to see you are disappointed with the XAV-72BT, we have forwarded your comments and observations to the relevant Sony team for investigation.

  • Another iPhoto 6 bug

    Amusing but yet another iPhoto 6 bug (6.0.2). Boy, does this program need some work.
    I created a new library, set alias on so it loads from my iView MediaPro layout, and am busy importing. In the information tab on the bottom left, it tells me its busy importing 1595 photos with a total size of 15066192772 GB. I wish.
    iBook 14" 1.42   Mac OS X (10.4.3)   1.5GB

    Did it finish loading the iView files? If so check the size at the bottom. If it's still incorrect and extremely large try rebuilding the library, launch iPhoto with the Command+Option keys depressed, follow the instructions to rebuild the library, while selecting only the database option. That may clear up the problem.
    I didn't note the size when I was importing my iView collection but iPhoto does reports the correct size now.

  • Another SQL Developer bug - End of file in comment

    I found another SQL Developer bug in version
    If I try to compile some package from file (so I open file with package body in SQL Developer and assign it to some connection) with this kind of comment: /* comment */ behind end of package, I get this error
    I got Error(1250,28): PLS-00111: end-of-file in commentFunny is, that when the package is compiled directly from the database - it works.
    When I try to compile the package from file with this kind of comment --comment behind the end of package, it also works...                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   

    Hi, I think I finally got it. This looks like an ugly fat bug :)
    First, we are not using the .sql extensions. For package specification - we use .pks. For package body - we use .pkb.
    Create this script:
    END TEST_xxx; /*0123456789*/Now save this as e.g. "TEST.pks" file. Open this file in SQL Developer and compile it. You will get the "Error(3,27): PLS-00111: end-of-file in comment".
    Now look at the result in the database -> Open the package specification from the database and you see this:
    create or replace
    END TEST_xxx; /*0123456789*The last slash is missing...
    Now go back to the file with the package specification and delete one letter from the comment. Compile it again... it works now.
    It looks like the length of this kind of comment is limited to 9 characters.
    The limitation is there only when:
    1) Compiling from file with different extension than .sql !!! If you rename the file to "TEST.sql", SQL Developer opens it as a script file and runs it as a script, so there is no problem with it.
    2) It has to be this kind of comment: /* */. One line comments are not limited.

  • FB3 Beta 3 - another organize imports bug

    I'm getting lucky :-) Here is another organize imports bug in
    FB3 Beta3...
    If you have some simple hierarchy where base class defines
    public (or protected) method, and sub class tries to override this
    method you will encounter this bug. Let say that base class looks
    like this:
    package test {
    import flash.display.Shape;
    public class BaseClass extends Shape {
    public function BaseClass() {
    public function myMethod():void {
    trace("In BaseClass.myMethod()");
    and that sub class looks like this
    package test {
    public class SubClass extends BaseClass {
    public function SubClass() {
    Now, if you try to override myMethod() from BaseClass and
    start typing in subclass something like
    override public function m
    and use Ctrl+Space, FB will insert appropriate method but it
    will also insert errorneous import statement like this:
    import test.BaseClass.myMethod;
    So you will end up with sub class which looks like following:
    package test {
    import test.BaseClass.myMethod;
    public class SubClass extends BaseClass {
    public function SubClass() {
    override public function myMethod():void {
    Wrong import is correctly marked as error but issuing
    "organize import" does not remove it so it must be removed
    Damir Murat
    PS: Sorry for bad code formatting but there is no option for
    inserting in-line code and attach code is a little bit

    Damir Murat,
    Did you already file a bug for this? If not, would you mind
    adding it to the public bug base so we can track the issue.

  • Another preview related bug???

    Recently I reported an issue (bug) with preview and
    non-auto-update variable. See =1364202&enterthread=y
    I have another issue with preview:
    - I update text within the body of a topic (I DO NOT toch
    header/footer that are set in template)
    - Do a preview
    - Close/save topic
    - RH comes up with dialog saying:
    "This topic was created from a template and the header of
    footer has been modified.
    What would you like to do:
    - Apply this modification to all topics created from the
    - Apply this modification to this topic only"
    Again, I never touched header/footer.
    Can anyone using 7.0.2 confirm this behavior?

    > See if this helps. Suggests turning off auto update.
    This doesn't help because a preview updates the date
    variable, even when auto update is set to off. When the topic is
    not edited, RH doesn't prompt to save the topic and consequently
    the updated date isn't saved . With edits, save dialog comes up and
    additionally header/footer dialog because date in footer has
    See also my earlier post here: =1364202&enterthread=y
    Secondly, I really need it on auto because I'm running
    everything through batch files
    I think that we need an option like Colum McAndrew described
    in the thread you're referring to. An option not to update a
    template variable when applied to a topic, or when previewing a

  • Another -C check bug

    Here is an interesting run-time check bug. I have an internal subroutine where an array index is changed in another internal subroutine by host association. The run-time check misses the fact that the index has been updated. Here is an example. It seems to relate to the use of a derived-type as well.
    program test
    implicit none
    type my_type
    integer, allocatable :: type(:)
    integer :: size=0
    end type my_type
    type(my_type) :: obj
    call sub1()
    subroutine sub1()
    call incr()
    end subroutine sub1
    subroutine incr()
    end subroutine incr
    end program test
    Here is my result:
    obj%size= 1
    ****** FORTRAN RUN-TIME SYSTEM ******
    Subscript out of range. Location: line 14 column 12 of 'test2.f90'
    Subscript number 1 has value 0 in array 'TYPE'

    OK, I figured out the problem. I am getting the __SUNPRO defines, but used them in a way that fpp did not substitute them. The problem I have not is that -xpp=cpp does not work because the flag -Y<path> is given, which is not a standard cpp flag, and I just get an error message.
    I am guessing that Sun cpp accepts a -Y flag, and sun Fortran assumes that it is standard. If so, maybe a good solution would be just to distribute Sun's cpp along with fpp. Another problem is that cpp is called with a specific path, so there is apparently no way to override it. So, it looks to me like this is a bug. But, it seems unlikely that nobody would have noticed it, unless everybody sticks with fpp, or if the -Y flag is new in this release.

  • Another spanned clips bug?

    I've read that Adobe recently fixed a spanned clips bug. Well here's another one (at least on my system):
    I have several spanned clips recorded with my Sony FS700 (MTS-files in AVCHD-container) and my Panasonic P2-camera (P2 MXF-files). When using Adobe Media Encoder (AME) to convert to ProRes, the spanned clips are joined right, but AME encodes the same material several times. The result is several copies of the exact same encoded material written to disk.
    Here's how it works:
    In one case, my camera had split my recording into 4 individual files. I expected AME to a) either join them and output one long file or b) not to join them and just output 4 individual ProRes files. Instead I ended up with 4 joined identical 32 GB files on disk. I did it again and noticed that AME actually encoded the same material 4 times in a row. What a waste of time and space …
    When using Sony MTS-files, AME creates different filenames for each clip (,, When using Panasonic MXF-files, AME put _1, _2, _3, etc. at the end of the filenames.
    In my opinion, AME should have a tick box where you can chose "join spanned files" or not. If it had such a box, it would chose to leave it off most of the time. That way it would be much easier to check if AME has converted all the files or not. It would be 32 files in = 32 files out, not 32 files in = 2 spanned files + x small files out … Nowadays, I have to doublecheck everything before formatting my cards.
    I'm using Adobe Media Encoder v. (64-bit) and OSX Mavericks 10.9.1 on a late 2013 Macbook Pro 15-inch Retina 2,3 GHz i7 16GB RAM 512 SSD.

    Jim Simon, let me explain:
    1. When I drag MTS-clips into AME, the software generates several copies of the same spanned clip during conversion. (They pop up in the queue while AME is converting).
    2. When I drag MXF-clips into AME, the software generates several copies of the same spanned clip before conversion. In the screenshot, which was taken after conversion, you'll see that the file numbers begin with 0018, 0019, 0019, 0019, 0019, and then jump to 0023, 0023. Well, what I dragged in was 0018, 0019, 0020, 0021, 0022, 0023, 0024 etc. So I believe AME skips filenames that are elements in a spanned clip, and then multiplies the the process all by itself. But, yes, I could manually examine the queue and erase identical clips after I drag files in. But that is just not a good way of working …
    So, AME behaves differently with spanned MXF and MTS-files, but none of them are handled right.

  • ANOTHER Lightroom 5 Bug??

    This is another bug that I had during the Beta which I hoped would have been solved. It is difficult to reproduce but happens frequent enough to be a real pain.
    Using the adjustment brush or gradient tool, I can apply settings to photos. Then when I switch to a new photo, I can select the brush or gradient, but I cannot apply it to the photo. Nothing happens when I paint or drag gradients. I can select and deselct the tool as many times as I want and even switch between tools. Only way to get it working again is to restart Lightroom.

    True.... except that in the Beta it was more the gradient tool causing this issue and now it is mostly the adjustment brush. I am not ruling out the fact that it can be something on my side... Could be a plugin or something causing this too. Once I can replicate the problem I will post the steps - but for now I am just keeping an ear out to see if anyone else have this issue.

  • Another iOS packager bug

    Came across another bug in iOS packager. In my project I have a function looking like this:
    private function sample():Object
         var iValue:int = 10;
          return false ? iValue : null;
    It correctly returns 'null' if packaged in ipa-debug-interpreter, apk-captive-runtime modes or if running in ADL. But it returns '0' if packaged in ipa-ad-hoc mode. I had to spend a whole day to figure out where is the problem. This is not the first type cast issue I came across. And it takes a lot of effort everytime to debug (10 minutes to build the project!). I'm breaking a dead line giving my customer an excuse that 'Adobe packager for iOS does not work right'. Which sounds like total BS of course. Adobe, please, get this straight. It is hard enough to develop with AIR for mobile. Bugs like this one make it much worse. Either way, I'm planning to advocate for using native tools in our next projects.

    I'm still using AIR 3.2. Unfortunately, I don't have a chance to try latest AIR 3.4 at the moment. But I will check the same code when I update AIR SDK.
    The code I posted is not a real code of course. I had to strip some logic and modify operators a bit. But I had hoped the bug would still reproduce. From my experience, most of the iOS packager bugs are caused by the rules of type casting that are not AS3 compliant. I have an impression that type casting rules used in the packager are more like classic C type casting rules. As the result, same code executes differently on iOS and Android|Windows. And it has being a huge problem for me.

  • Another Mountain Lion bug

    Hi all.
    I have discovered another bug in Mountain Lion.
    I have Adobe Creative Suite 6 Installed (including InDesign CS6) and have had to also install my old InDesign CS4 to work with clients that use it.
    I have chosen an InDesign document that was created in CS4 (and hasn't been opened in CS6) and right clicked - 'Get Info'
    Changed the 'Open With' default from CS6 to CS4.
    So far so good.
    I then clicked "Change All", I get the confirmation message box, and as soon as I click "Yes, please change All to CS4" It immediately changes the default setting back to CS6.
    If I change the "Open with" default for a file to CS4, and leave it at that, it works fine for that file,
    but the "Change All" function seems to be broken.
    The Change All function seems to work fine on Leopard and Snow Leopard. I haven't tried Lion, but I suspect that is where the trouble starts. (It has with other bugs.).
    Any light that any of you could shed on this, or even fixes involving the Terminal and the Unix commands, would be greatly appreciated.
    Thanks for your time.
    Also this forum has a problem with the question form.
    below it has asked me for my product - "Macbook Pro"
    Then Operating System - and it gives me a choice of iOS from 4 to 7
    As far as I know, Apple hasn't inflicted mobile phone operating systems on computers. yet.
    perish the thought.

    Change All works quite well for me for every version of Mountain Lion and on several different computers. It's not an OS X problem. You have some other problem such as possible file permissions' issues. You might try repairing ACLs and permissions in your Home folder by using the "resetpassword" Terminal command that you may access via the Recovery HD. You will not be resetting passwords, btw.
    Reset User Permissions and ACLs in Lion/Mountain Lion
    Boot to the Recovery HD:
    Restart the computer and after the chime press and hold down the COMMAND and R keys until the menu screen appears. Alternatively, restart the computer and after the chime press and hold down the OPTION key until the boot manager screen appears. Select the Recovery HD and click on the downward pointing arrow button.
    From the Utilities menu select Terminal. At the Terminal prompt enter: resetpassword. Press RETURN. When the window opens select your startup drive where it says "Select the volume containing the user account:" At the bottom of the window you will see, "Reset Home folder permissions and ACLs." Click on the Reset button.

  • Found another Belle calendar bug (Nokia, when is B...

    I know, Nokia does not react here but writing to Dutch Nokia Care is no use: either no answer or a standard answer like "Your C6-01 is a high quality business phone with advanced features ... blah blah blah".
    But okay, found another bug in the Belle calendar. In the calendar widget to be precise: I have a easy week, no appointments. Next appointment is Monday 12 March at 09:15. Much to my surprise I did see the next thing in my calendar widget this morning Monday 5 March: at the top "monday" and below that 09:15 Doctor. I see that today, on Monday the 5th while that appointment is set for Monday the 12th. But that bugged calendar widget is not showing a date, just "monday".
    So besides the stupid 1 line mention bug, it also shows info that is confusing to say the least.
    So please Nokia, fix the calendar!!
    (and no, I do not want that ComingNext app )

    Export the region as an audio file first. Right-click the track select Export as audio file.
    Then import the track into the new project.
    Alternately, do a Save As of the project as a different file name.
    Re-open and rearrange the tracks as you please.
    Hope that helps.
    Message was edited by: Beatoven

  • Another iTunes 7 bug

    I love iTunes 7 except it has few bugs in it, for example if a music folder contains wmp album art itunes 7 will crash if playing music from that folder and you click iTunes's browse button.
    iTunes 7 likes a lot memory, windows mediaplayer uses 18 Meg compared to iTunes 7 which uses 60 meg in cover browser mode or 45 Meg in general.

    two days ago I made the switch to iTunes 7, and at first was quite happy about it, mainly because impressed by CoverFlow.
    but today I noticed that all the covers were missing from my 30Gb Photo iPod.
    So I checked the Support area of looking for a solution and I spotted this thread and now while trying to reload the covers I want to ask something to Apple:
    Why did you release such a crappy application? what are you afraid of, Zune and is crapware? Come on act as Apple, delight your customers and they will not leave you, act as any other and there will no any reason for choosing you and your products.
    andrea from Italy

  • Another incedibly stupid bug

    If you email an image from within Aperture the programme opens up mail but then nothing happens. You have to quit mail and then restart it again for a draft to pop up as a new message with the image attached so that you can send it to the recipient. This does not happen if mail is already open.
    Ever get the feeling this product was rushed to market!

    Bugs are universal. What you've found is something that doesn't work on your system. You can tell us you've found a glitch but you can't go around screaming A BUG A BUG until we know it's universal. This is not a bug in Aperture.
    Several of Apple's i-series and pro applications have hooks to send files directly using Mail. Has it ever worked with any other app?
    Emailing an image out of Aperture appears to work on my system. I say "appears" because I didn't actually send the message. But Mail launched and some kind of image was attached. All I had to do was complete the address and write a note. I did not actually open the attached file, I just pushed the button to see if it worked. It seemed to.

  • Another Flickr Publish Bug?

    I have no objection to the images I upload to Flickr being accessbile to public searches.
    Yet every time I publish or republish a photo, Flickr's setting ... "It is hidden from public searches" seems to get set for each image - even if I manually override for an individual image using the Flickr Web interface and then republish from LR it gets set back to this state - see below...
    I have set my Flickr user profile with ...
    so I don't think this behaviour is being caused by Flickr...
    and I cannot see any settings at the LR Flickr Publishing settings which would cause this ...
    Any help in either correcting my lack of understanding or confirming it a bug would be appreciated.
    Many thanks

    I can confirm the bug in LR 3.0, it happens every time I republish.
    There is at least one other annoying problem caused by republishing. If you have posted the photo into a group thread (by copying and pasting the HTML), the link from the thread back to the photo gets broken when you republish. It shows up as "This photo is currently unavailable".
    I haven't downloaded LR 3.2RC yet to see if these issues have been fixed.

Maybe you are looking for