Latest Bugs & Tasks
CDPlayer doesn't work with most CD drives, especially USB ones. It's been deleted out of Haiku's source tree for this reason in favor of CDDAfs which can play CDs from nearly any drive.
I think it would be handy to being able to open containing folder in hyperlink mode (command + right click)
Selecting any image and Clicking Convert file button crashes WebPositive.
I've safe mode booted and tried safe mode video, but that didn't help. I displayed debug output to the screen and disabled pageination and the output stops right after the message about:
REG: failed to open shadow passwd DB file "/etc/shadow": No such file or directory
That's the last line of the debug output. It just sits there after that and doesn't boot (I waited like 20 minutes and nothing had happened yet, multiple boots of that and other recent revisions had the same behavior.)
I'll attach my listdev output and syslog(s) from my working hrev46677 install.
I have an IO Crest SI-PEX40057 SATA III PCI-e card in my machine, and if I hook any hard drive to it, Haiku completely fails to boot and instead just reboots the machine as soon as it shows "Loading system" on the screen, before the graphical boot loader or anything else appears.
"IO Crest SATA III 4-Port PCI-e 2.0 x 2 Card with Marvell HyperDuo RAID Mode Support and Low Profile Brackets SI-PEX40057"
Merely unhooking the drive from the card "fixes" the problem and everything works fine.
I tried hooking up two different hard drives to the card, and both cause this problem, even though neither drive is the Haiku drive. These are just extra storage drives. (And everything works fine in Windows and Linux.)
Also, even with hrev46284 and earlier, if you try to enter the safe mode boot menu by holding down shift or space, this will cause a reboot before you load anything.
I went back to hrev45284 (100 revisions back) and still had the same problem, so I'm not sure how far back that issue goes (reboot when trying to enter safe mode menu with shift/space).
And again, just unhooking the drive from the card restores expected functionality and the system boots properly.
While working on bringing DVB support back to life I encountered a bug that was introduced by the commits [a] and [b].
The bug hides in the realm of an app requesting a specific decoder (MPEG2 video and MP3 audio in the case of DVB support). When the app requests these decoders via BMediaFormats::GetFormatFor() (see [c] for a code snippet in the dvb.media_addon) it won't find any decoders, because the AddOnManager ([d]) didn't load the ffmpeg media plugin and its codecs yet.
I've commited two unit tests (MPEG2 video decoding [f] and MP3 video decoding [g]) to the haiku repo, that demonstrate the bug. For example: Just set a breakpoint at [h] and see that the status returned is not B_OK as one would expect. When you step in to the call to formats.GetFormatFor() one line earlier, you will see that there are no codecs loaded yet.
I tried the following solutions:
- Load the plugins (_RegisterAddons()) within the constructor of the AddOnManager.
- Call AddOnManager::LoadState() (After reintroducing the Method LoadState() in the AddOnManager) from within the constructor of BMediaFormats.
Both solutions successfully (as in tried and confirmed) emulate the behavior of AddOnManager when it was still part of the media_server. Back then the media_server issued a call to AddOnManager::LoadState() in the method ReadyToRun() (see [e]) resulting in the loading of all ffmpeg's codecs.
But both solutions smell bad to me. Unfortunately I can't really tell why it smells bad to me. As of now I would rather prefer the former way of handling media plugins via the media_server.
There exists a mailing list discussion thread [i] with Adrien explaining the reason behind both commits ([a] and [b]) and Axel outlining a possible solution on the server side.
[a] Move media plug-in support to application side. http://cgit.haiku-os.org/haiku/commit/src/kits/media?id=2feaa37f244d707251f7fe1184ce4f7d30251e2d
[b] Urpdate AddOnManager and FormatManager for Media Kit. http://cgit.haiku-os.org/haiku/commit/src/kits/media?id=bf3b475c3838eb2da1f4a97b214535698902380b
[c] dvb.media_addon: https://github.com/haiku/haiku/blob/master/src/add-ons/media/media-add-ons/dvb/MediaFormat.cpp#L160
[d] Media Kit's AddOnManager: https://github.com/haiku/haiku/blob/master/src/kits/media/AddOnManager.cpp
[e] media_server's old code location of loading all ffmpeg codecs: http://cgit.haiku-os.org/haiku/tree/src/servers/media/media_server.cpp?id=hrev46599#n152
[f] mpeg2_decoder_test: http://cgit.haiku-os.org/haiku/tree/src/tests/kits/media/mpeg2_decoder_test?id=hrev47470
[g] mp3_decoder_test: http://cgit.haiku-os.org/haiku/tree/src/tests/kits/media/mp3_decoder_test?id=hrev47470
[h] breakpoint in unit test mpeg2_decoder_test where the bug shows itself: http://cgit.haiku-os.org/haiku/tree/src/tests/kits/media/mpeg2_decoder_test/mpeg2_decoder_test.cpp?id=hrev47470#n189
[i] mailing list discussion about this bug: http://www.freelists.org/post/haiku-development/Media-plugin-support-to-message-or-not-to-message
- It does not work on newer hardware
- There is no way to fix it on newer hardware
- CDDAfs+CDDB_daemon does the same stuff and works on all hardware
As is, the report is not very useful. Generally the use of downloaded build feature packages works just fine. Occasionally a dependency to a build feature is not specified correctly, in which case multi-job (and even single-job) builds may fail.
Please reopen, when you can provide the necessary information: build platform, build configuration, revision, build log.
Applied in hrev47472.
I have a Targa MediaBox 320GB external HDD from a fair few years ago at this stage which I have an NTFS and BFS partition on.
Over USB, the BFS partition writes at an acceptable speed. NTFS however writes extremely slowly, as in sub-50KB/sec. This was checked on two computers (both running different post-PM revisions)
The same drive also has an eSATA connector, over which writes are significan