The 20100731 release of the 'bijou' respin of MythTV 0.23.1 will soon
be available on atrpms-testing.

bijou is an enhanced version of the ATrpms MythTV packages with useful
patches and bugfixes. The database is never changed so users can
always move freely between the bijou and stock versions.

This is the first bijou version based on MythTV 0.23.1; see
<URL:http://www.mythtv.org/wiki/Release_Notes_-_0.23.1> for its
changes. 0.23.1 changed the protocol, not the database schema. Users
can freely move between 0.23 and 0.23.1, but all backends and
frontends must run the same version to interoperate. In other words,
no keeping 0.23 (whether stock or bijou) on one box while updating
everything else to 0.23.1; it's all or nothing.

This release of bijou fixes a bug with a signal-monitoring patch
(#6719) which broke multirec with DVB tuners, and significantly
enhances performance of mythlink.pl (r25386). It also removes the
emergency vuvuzela audio filter (#8568) introduced with 20100616; the
filter may reappear in 2014, though.

Previous changelog for 'bijou' based on MythTV 0.23:
* Adjustments to ThreadedFileWriter's buffers. Significantly improves
recordings' integrity when destination disks are stressed, at the cost
of increased RAM usage. (That said, on my frontend/backend I've
recorded four HD streams at once without swapping.) My work.
* Three Hauppauge HD-PVR-related improvements. Two add signal
monitoring to HD-PVR tuning and also slightly benefit FireWire users
(#6719, #6611), while the third fixes an issue with h.264 LiveTV
(#6602). Users should, in theory, be able to get rid of any
post-change sleeps they put into their HD-PVR channel-change
scripts.
* Automatically scale number of user jobs based on system load
(#2782).
* Fix for Jumppoints not working when OSD is present (#7939).
* Improved detection of audio tracks when transcoding (my variant on
#1841).
* Avoid scheduling back-to-back recordings on the same card even if on
the same channel (#8429). Primarily of interest to multirec
users. "Always" enables this feature, while "Different Channels" and
"Never" are the preexisting options.

-- 
Yeechang Lee <[email protected]> | San Francisco

_______________________________________________
atrpms-users mailing list
[email protected]
http://lists.atrpms.net/mailman/listinfo/atrpms-users

Reply via email to