Latest Bugs & Tasks
GLife crashes after walking through the list of screensavers up and down.
This is another variant of #12448, follow the instructions there to temporarily fix it.
Just downloaded and JAM'd the latest Haiku x86 revision tonight (4/18/16). And it stops, at the point it is trying to download libsolv, doing a wget procedure or something. Says "NO_HAIKU_DOWNLOAD_PERMITTED" or something. I know this is rather vague, but hoping someone else has run into this, so they know what I'm talking about. I can try to get an image from my Haiku system (I'm writing this in the house on a Win10 laptop) later on, if necessary.
Yumi currently doesn't seem to accommodate installing Haiku. Feel free to bring it up with the Yumi developers, there is nothing wrong with the iso file in question.
For support questions, please use the Haiku general mailing list or IRC instead.
See attached File,
i wonder if there is a problem with iso-File-image
(no correct format / structure).
used programm, yumi under windows & last nightly (50226-x86_64-cd)
I've done considerably more testing, and I'm convinced this is not related to #12412.
The other KDL is reported as only hsppening on the first boot after an install; this one is reproducible at will. The "soft_fault" that I consistently see (shown in the syslog excerpt above) does not appear anywhere in the #12412 syslogs. The fact that the KDL is momentary is also totally consistent -- and totally strange to me!
I have established fairly solidly that it only happens if I move the mouse during boot. If I don't touch it, the boot is always OK.
I noticed that the fault is always just preceded by loading the wacom driver, so I tried installing an old pre-PM copy (that has never given any trouble) in non-packaged... It made no difference to the crash (though it seems to work just as well).
I hadn't been using my Wacom, but I plugged it in this time, and found that moving the pen has exactly the same effect as moving the mouse. OTOH I haven't been able to cause a crash by activating the laptop's TrackPad. Both the mouse and Wacom are USB, so maybe the problem is somewhere in that area.
Reopening the ticket...
[BTW I still have to use my custom Wacom Intuos device (not the driver), because my submitted patch #4847 of a few years ago is still hanging...!]
Firewire-0 duplicate, please refer to #12448.
Native mode issues resolved via hrev50232.
Tracking the lack of hardware scaling as enhancement #12723
We should investigate leveraging the hardware panel scaler on intel_extreme supported chipsets.
I think good chances are that you installed a custom version of ffmpeg and it clashed after some Haiku update.
Closing the ticket as invalid.
Monitor ports with watch sysinfo -ports beside the Web+ window
Zoom in and out for a few seconds; if you close the tab soon enough, ports are returned; if you wait too long, W+ closes down without warning and syslog reports "ports exhausted, could not create debugger"
For whatever it's worth...
This is hrev50173.
- create a save panel with "filepanel --save"
- press SHIFT + ALT + C (or X or V)
Attached the rather long full crash report. Here's a cut:
thread 900: w>filepanel: Save state: Exception (Segment violation) Frame IP Function Name ----------------------------------------------- 0x7052e040 0x19b53e5 BPrivate::BContainerWindow::MessageReceived(BMessage*) + 0x9 Disassembly: BPrivate::BContainerWindow::MessageReceived(BMessage*): 0x019b53dc: 55 push %ebp 0x019b53dd: 89e5 mov %esp, %ebp 0x019b53df: 81ec3c010000 sub $0x13c, %esp 0x019b53e5: 57 push %edi <-- Frame memory: Unavailable (Bad address) 0x7052e190 0x19f4d0b BPrivate::TFilePanel::MessageReceived(BMessage*) + 0xa67 0x7052e280 0x1c382b7 BHandler::MessageReceived(BMessage*) + 0x37b 0x7052e3a0 0x1d1d58f BView::MessageReceived(BMessage*) + 0x33b 0x7052e490 0x1c382b7 BHandler::MessageReceived(BMessage*) + 0x37b . . . 0x7056cc00 0x19b5596 BPrivate::BContainerWindow::MessageReceived(BMessage*) + 0x1ba 0x7056cd50 0x19f4d0b BPrivate::TFilePanel::MessageReceived(BMessage*) + 0xa67 0x7056cd80 0x1c3e5a5 BLooper::DispatchMessage(BMessage*, BHandler*) + 0x59 0x7056cf60 0x1d25ed8 BWindow::DispatchMessage(BMessage*, BHandler*) + 0x182c 0x7056cf90 0x19ef6a0 BPrivate::TFilePanel::DispatchMessage(BMessage*, BHandler*) + 0x24 0x7056cff0 0x1d2a37a BWindow::task_looper() + 0x28e 0x7056d020 0x1c3fa4d BLooper::_task0_(void*) + 0x3d 0x7056d048 0x13aed21 thread_entry + 0x21 00000000 0x60cd6250 commpage_thread_exit + 0
Ticket #12719 (Team monitor: window size is partially hiding the Force reboot and Cancel ...) closed
I haven't yet been able to bisect what revision this regression was introduced in, but at least in hrev50216 AAC and Ogg Vorbis decoding appears to be broken. The audio plays with stuttering artifacts, which appears to be due to something along the chain deciding that the format sample size is 32 bits rather than 16. This occurs for both standalone audio files and audio tracks in video files. This problem is not observable with either MPEG 2 or 3 audio.
Ticket #12719 (Team monitor: window size is partially hiding the Force reboot and Cancel ...) created
I noticed that the Force reboot and Cancel buttons are being partially hidden due to the Window size. Please see the attached screenshot.
Walter (Revision hrev50194)
I noticed that when making various Tracker setting changes via the Window or Attributes menu options, they do not persist, which is a regression when compared to older versions of Haiku.
Walter (Revision hrev50194)
- open a Tracker window and navigate to the System folder (in root)
- perform various user settings via the Window or Attributes menu
- close Tracker window
- re-open a Tracker window and navigate to the System folder
- (BUG) observe that the user settings performed earlier do not persist and return to default settings
I would expect that the user settings for Tracker windows would persist regardless of folders being targeted (Home, System, etc...).
Currently, when performing user settings for Windowd and Attribute options in Tracker for the System folder, they do not persist.
hrev50213: Media Server shows a popup notification about being ready to use on every boot, which seems a bit excessive (and not very useful). See attached screenshot. I suppose this should only be shown upon manual restart of media services.