OpenWrt v24.10.8 Release
Important
The NVIDIA SDK was updated to version 13 in this release. This means that the minimum supported driver version is now 570. If you experience any issues with NVENC, please ensure that your GPU driver version is fully up to date.
OBS-Studio-32.2.1-Sources.tar.gz: 6a2532b1094bc51bc2fdeb1068d5c19cfe04216191a5b35c8707625401a80bf4
OBS-Studio-32.2.1-Ubuntu-24.04-x86_64-dbsym.ddeb: 7fd2a7f043658ce9504f9d31ec5af45067fdfd49d41717897f3d60123259809d
OBS-Studio-32.2.1-Ubuntu-24.04-x86_64.deb: f3ce385c9157a33db7219953dc672ae566aefe4d1ac1417fff1e2114de3316b5
OBS-Studio-32.2.1-Ubuntu-26.04-x86_64-dbsym.ddeb: 27c9a45baf6679f7f992e2f61c906cef4712172ecfc2b1eb0a28b46483024687
OBS-Studio-32.2.1-Ubuntu-26.04-x86_64.deb: 9411b2eb1cd64c0e4f442f017e482689cc59795d352c6c120356c7364c8c13be
OBS-Studio-32.2.1-Windows-arm64-PDBs.zip: 48f44ca5cb15be42179d3d2eaf6e2a68b38f9a8ac32c1482bea8661f4c8c2f73
OBS-Studio-32.2.1-Windows-arm64.zip: 53f6bca41dc59153f30a9fca69a2a9ae1be6086cc8c592dca178cd80c59c7ab9
OBS-Studio-32.2.1-Windows-x64-Installer.exe: bbb95e52b96ad9b7ccd5abd13121379d29774d6cc5fdbef82ffa249e8a24a289
OBS-Studio-32.2.1-Windows-x64-PDBs.zip: e6dcf4a06b4457cd54006b2a602202095482ccd1cb82e455da6a57ef97fd124f
OBS-Studio-32.2.1-Windows-x64.zip: db64a2934f8261f85b1410b84be011207a0afda5400d008289f1f1e211bcc7de
OBS-Studio-32.2.1-macOS-Apple-dSYMs.tar.xz: 635d5cbf8971ddb512c367d18f32773e44db5f612e08735b7f5e953f28e28422
OBS-Studio-32.2.1-macOS-Apple.dmg: 6120c995614be17ecd0ee0877514a88b121249e6261cde46d1440b87d7ffd70c
OBS-Studio-32.2.1-macOS-Intel-dSYMs.tar.xz: c90a80e6e8bc503dfd9314e599743b922d7593c16a258defe0b959077d0d0cda
OBS-Studio-32.2.1-macOS-Intel.dmg: 6900a7a6d4422956114cac3c148d871307fdb0530160c2cbb4e97f624c9f85a5
In the 1.60 update, we have introduced the Improved Material System for selected trucks for both Euro Truck Simulator 2 and American Truck Simulator. And today, we bring you a look behind the scenes at how this feature came to life!
The two main people working on this feature are our colleagues Daniel and Martin, who were and still are implementing the system for trucks in both games, and also for cars in the upcoming Road Trip project for American Truck Simulator.
"I've been working at SCS Software for over thirteen years. I started as a 3D Generalist, then worked as a 3D Vehicle Artist and Vehicle Team Lead. Today, my role is the Vehicle Technical Leader.
My work bridges the gap between the graphical and technical aspects of development. I collaborate with programmers to implement vehicle features into the engine, while also helping artists establish efficient workflows. I also design new tools and technical improvements.
My task on the improved material system was to identify the problem, propose a solution, and collaborate with programmers on its implementation into the engine. Next, we needed to set up a practical workflow for the vehicle team so that the system could be used consistently across other vehicles. The programmers created the necessary support in the engine and shaders. The graphic designers then converted and fine-tuned the materials for specific trucks."
"I work as a Senior 3D Graphic Designer specializing in vehicles. I also worked as Head of Content for the Road Trip project. I participated in selecting the vehicles and their specific variants, handled research and pre-production, provided expert consultation, and subsequently worked on the actual creation of the vehicles. I also helped Dan fine-tune changes to the material system.
Cars have been a long-standing passion of mine, especially sports cars and classic cars - particularly American ones. Thanks to this, I was able to bring my own experience and knowledge of American automotive culture, history, and the technical development of individual models to the project.
My main task was the 1967 Ford Mustang and everything related to its visual and content preparation. I was involved in selecting the specific car and its variant, conducting research, gathering references, consulting during data collection, and the actual creation of the model and materials.
During the development of the new material system, I prepared and fine-tuned the individual surfaces on the Mustang. Together with Dan, we used this car to verify how the new technical solution behaved in practice and which values provided the most accurate results."
How did this project start?
"Development began while we were working on the Road Trip project. The interiors of passenger cars are smaller and darker than those of trucks, so the shortcomings of the original system were more noticeable in them.
Aside from direct light, the original system had no way to render light within the interiors. In the real world, a large portion of the visuals consists of so-called indirect, or reflected light (GI). However, the game did not work with this concept at all and was not designed for it. We knew we needed to change this somehow.
The second problem was that the interiors of the trucks contain many different materials, such as fabric, leather, plastic, painted surfaces, metal, and glass. The original system was unable to render them accurately, especially under indirect lighting; everything looked very flat.
"Road Trip provided us with a suitable, isolated environment for development and testing. From the start, however, we designed the system so that it could also be used for trucks," says Daniel.
What did you have to do before actually starting to implement the improved system?
"We needed to map out the actual vehicles and the materials used in their interior in detail through extensive research. I studied magazines, photographs, available documentation, and individual trim levels. While gathering data, we had the opportunity to see the specific car in person, speak with its owner, and document its construction and appearance in detail.
It wasn't enough to simply determine that a certain part of the interior was made of, for example, plastic, leather, or metal. We also had to examine the surface texture, the degree of gloss, the way the material reflects light, its wear and tear, the color shade, and the differences between individual parts.
This research laid the foundation upon which we could later assess whether the materials in the game corresponded to the actual vehicle," Martin told us.
"We also had to decide which direction to take. One of the key requirements was maintaining performance, so we looked for approaches that didn't require complex computational operations and sought techniques that would achieve good results with minimal changes to computational complexity. I believe the result of our efforts is a noticeable improvement in graphics with minimal impact on performance," Daniel shared with us.
How did the process of bringing the new system into the game look?
"We needed to implement changes to the engine regarding how the game loads and handles reflective textures. A reflective texture is essentially a cube where each face shows a reflection in a different direction relative to the player. Using it is significantly more efficient than calculating actual light reflections using ray tracing. We made several changes to the code to gain direct access to individual mipmaps. A mipmap is a scaled-down copy of the original image, typically used when a textured object is farther away from the player to eliminate unappealing texture aliasing. In our specific case, however, a lower resolution automatically results in a softer reflection, which can be used for materials that do not have a 100% glossy surface but rather a physically rougher surface, causing the reflection on the material to be more diffuse.
This way, we created several different levels of reflection smoothness, ranging from perfectly glossy surfaces like chrome, through smoother reflections such as those found on leather seat materials, to rough, nearly non-reflective materials like fabrics, where one side of the reflection cube is only 2x2px. In our case, it replaces the Iradience map, which means it primarily serves to project the surrounding light palette onto the given material (color cast). The game was already calculating the mipmaps themselves, which means this change costs us practically nothing in terms of performance - and that is the main reason we decided to use this approach.
Along with the material changes, we also needed to rebalance the contrast and lighting throughout the game to eliminate extremely dark areas and achieve a more realistic sense of lighting.
Unlike the original solution, where reflective textures were used only for highly reflective materials, particularly metals, the revised system applies a reflective texture to every single material in the vehicle's interior. However, they differ in how strongly the reflection is visible in the final image and in the softness of the reflection applied. This ensures that even less reflective materials - especially plastics - convey a sense of reflected light, color cast, and improved contrast, particularly in shaded areas of the interior. Players will now notice that the entire interior actually reacts to the truck's surroundings; for example, when driving past trees, the part of the interior near the windows takes on a subtle green tint. This makes the game feel much more realistic than before, even without the computationally expensive global illumination (GI) calculation.
Once the technology was ready, we needed to determine how to adjust the individual materials under the new conditions. Since each material now includes a reflective component, we had to completely rebalance all the settings for each material. To ensure that existing textures would function correctly with the new settings, we also had to rebalance their color and specular components to the standard values we had established during our extensive testing.
The final step for system-wide deployment was to create a material library so that we wouldn't have to configure each material type separately for every vehicle," Daniel explains.
What were the biggest challenges in implementing the system?
"The biggest challenge was the diversity of the vehicles. The individual trucks were created at different times and used different source data, textures, and rendering methods. There is no single conversion that works for all trucks. Each completed interior has its own structure and requires a customized approach," says Daniel.
"Also, the individual properties of materials influence one another. Changing the reflectance or roughness might improve the appearance of one surface, but at the same time cause the material to behave poorly in a different lighting situation. Or a material that looked right in direct daylight might be too shiny in a dark interior or react unnaturally while driving at night. It was therefore necessary to constantly strike a balance between realism, visibility, and consistent behavior. The goal was not to make all surfaces more prominent or shinier, but to accurately capture the differences between them.
We reworked many of these steps several times during development. However, the result was not just materials for one specific car, but also experience and guidelines that will significantly facilitate work on future vehicles.
The process wasn't straightforward. It wasn't enough to simply set a few parameters according to a pre-prepared table. We had to figure out many of the values ourselves, and together with Dan, we tested them repeatedly right in the game," Martin added.
How did you manage to do the changes without affecting performance?
"Our players use a wide range of hardware. We didn't want to create visual enhancements that would significantly reduce the game's performance or even make the game unplayable for some players. Therefore, the system is not based on a new, resource-intensive lighting simulation. It extends the existing rendering pipeline and utilizes already available data more efficiently.
Performance was continuously profiled during development. The goal was to achieve a visible improvement with minimal impact on the graphics card and memory. Furthermore, the system is configured to function with a certain trade-off even when set to medium or low - in such cases, while reflections are not rendered in real time and some benefits, such as realistic color cast from the vehicle's surroundings, are lost, the materials themselves still look realistic and can be distinguished from one another," says Daniel.
So far, we've implemented the improved material system on four trucks across ETS2 and ATS. Rather than making the community wait until every truck has been updated, we'll continue rolling out the improved material system for other trucks gradually, allowing you to enjoy the improvements on some vehicles already while we complete the rest. As Daniel explains here:
"Each truck requires individual adjustments, a visual inspection, and testing of all variants in daylight, at night, in the rain, and in cloudy weather. Therefore, it was not possible to update the entire fleet at once. This smaller initial group will allow us to verify the entire production process, maintain quality, and gather feedback from players."
We hope you have enjoyed this in-depth look at how we work on the improved material system. Make sure to also add theΒ Ford Car Pack and the RAM & Dodge Car Pack to your Steam wishlist, so you can enjoy this feature on cars when we release them.
Don't forget to give our X/Twitter, Instagram, Facebook, Bluesky, TikTok, and YouTube a follow, as you'll receive updates about our games straight to your feed! Or subscribe to our newsletter to stay informed. Until next time, safe travels!
Changelog
================================================================
Wana boot and install OS through network (PXE)? Welcome to my new project iVentoy.
About iVentoy https://www.iventoy.com/
iVentoy is an enhanced version of the PXE server.
Extremely easy to use
Many advanced features
x86 Legacy BIOS, IA32 UEFI, x86_64 UEFI and ARM64 UEFI mode supported
110+ common types of OS supported (Windows/WinPE/Linux/VMware)
Turn any PC, laptop, server, NAS, or Raspberry Pi into a PXE server instantly!
......
Windows Installer
Windows No Installer (zip)
macOS - Universal
Linux - deb, AppImage or rpm
Windows intel x32 releases are marked -ia32-
ChangeLog:
Docker images have been built and pushed:
Docker Hub:
alexta69/metube:latestalexta69/metube:2026.07.24GitHub Container Registry:
ghcr.io/alexta69/metube:latestghcr.io/alexta69/metube:2026.07.24
The Stable channel has been updated to 150.0.7871.186/.187 for Windows and Mac and 150.0.7871.186 for Linux, which will roll out over the coming days/weeks. A full list of changes in this build is available in the Log
Security Fixes and Rewards
Note: Access to bug details and links may be kept restricted until a majority of users are updated with a fix. We will also retain restrictions if the bug exists in a third party library that other projects similarly depend on, but havenβt yet fixed.
This update includes 4 security fixes. Please see the Chrome Security Page for more information.
[N/A][518237034] High CVE-2026-16807: Out of bounds write in Codecs. Reported by Google on 2026-05-30
[N/A][522064153] High CVE-2026-16806: Use after free in WebMCP. Reported by Google on 2026-06-10
[N/A][523292588] High CVE-2026-16805: Use after free in Blink. Reported by Google on 2026-06-12
[N/A][524721670] High CVE-2026-16804: Use after free in Input. Reported by Google on 2026-06-16
We would also like to thank all security researchers that worked with us during the development cycle to prevent security bugs from ever reaching the stable channel.
Many of our security bugs are detected using AddressSanitizer, MemorySanitizer, UndefinedBehaviorSanitizer, Control Flow Integrity, libFuzzer, or AFL.
Interested in switching release channels? Find out how here. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.
Daniel Yip
Google Chrome
General
API
Media-Over-QUIC
WebRTC
RTSP
HLS
SRT
Dependencies
Binaries are compiled from source code by the Release workflow, which is a fully-visible process that prevents any change or external interference in produced artifacts.
Checksums of binaries are also published in a public blockchain by using GitHub Attestations, and they can be verified by running:
ls mediamtx_* | xargs -L1 gh attestation verify --repo bluenviron/mediamtx
You can verify checksums of binaries by downloading checksums.sha256 and running:
cat checksums.sha256 | grep "$(ls mediamtx_*)" | sha256sum --check
Note
If someone is asking you to pay money for access to UpSnap binaries, source code, or licenses, you are being scammed.
The official and only trusted source for UpSnap is this repository (and its linked releases).
Do not pay third parties for something that is provided here for free.
If you've been following our rework projects in American Truck Simulator, you may be wondering what's next after our recent focus on Route 66. Today, we're excited to share the answer! Our next major undertaking will be the Nevada Rework Project, where we'll give the Silver State a complete overhaul.
As part of this next phase, our map designers will focus on the entire state of Nevada, reworking all of its existing cities and road networks to bring them up to the quality standards of our latest content. Since Nevada was one of the original states released with American Truck Simulator, this rework will allow us to rebuild many locations from the ground up while preserving the character and atmosphere that make the state so unique.
In addition to refreshing familiar places, we're also taking the opportunity to expand Nevada with locations and road connections that were missing from the original version. One example is the city of Fallon, located east of Carson City. Alongside it, we'll also add the missing sections of US-95 that pass through Fallon from south to north, creating a more complete and authentic driving experience.
Throughout the state, you can also look forward to a variety of brand-new custom depots, offering more diverse delivery destinations and making freight transportation across Nevada feel even more immersive than before.
This is just the beginning of the Nevada Rework Project, and we're looking forward to sharing more previews from development as work progresses. Be sure to follow us onΒ X/Twitter, Facebook, Instagram, TikTok,Β Bluesky, and YouTube, or sign up for our newsletterΒ so you don't miss any future updates. Until next time, keep on truckin'!

Ever since we introduced the idea of a community-powered device database at State of the Open Home 2025, our goal has been clear: create a βWikipedia of smart home devicesβ based on real-world usage. In February, we took the first step by inviting Home Assistant users to voluntarily share anonymized device data to help us build it.
Β The Stable channel has been updated to 151.0.7922.47/.48 for Windows and Mac as part of our early stable release to a small percentage of users. A full list of changes in this build is available in the log.
You can find more details about early Stable releases here.
Interested in switching release channels? Β Find out how here. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.
Daniel Yip
Google Chrome
Thank you for your donations:
One-time
Monthly
url()/@import from <style> blocks in the sanitizer (#457)LOGIN_SHOW_TOTP and LOGIN_SHOW_VERSION config flags (#520)NEXT_PUBLIC_LOCALE_PREFIX build argumentui.rerenderFetchedEmails method (#668)onEmailsFetched and onSearchResults hooks and getSomeEmails JMAP methodonRecipientChipsChange hookwebauthn.getOrCreate API methodui:download-file consent permission)target/rel on links in plain-text message bodies and open signature links in a new tabmailboxIds replacementspf=none from downgrading a MAIL FROM spf=pass (#650)dompurify to 3.4.12 and next-intl to 4.13.3
Our wheels keep turning, and today weβre ready to share a teaser of another U.S. state currently in development for American Truck Simulator. Letβs see how good your guessing game is!
We are pleased to announce the third release candidate preview release of Jellyfin 12.0!
This is a preview release, intended for those interested in testing 12.0 before its final public release. We welcome testers to help find as many bugs as we can before the final release.
As always, please ensure you stop your Jellyfin server and take a full backup before upgrading!
Starting with this release, we are dropping the preceding 10. from our versioning. Thus, 10.11.x -> [10.]12.x = 12.x. The reason is simple: at this point in the project, we don't envision a hard break in the API like we planned way back in the early days, and this version scheme was causing a lot of confusion amongst users about what a "major" release was. For more information, please see the RC1 release notes.
The main goal of this release has been performance. 10.11.0 dropped a major backend rewrite, and while it was broadly functional, it had a lot of rough edges. This release seeks to polish out most of those rough edges and bring better performance to all users.
There are many other small fixes, improvements, changes, and translations. See our draft release notes here or below for the full list of pull requests. You can also view the Web side changelog here.
Note: You must be on Jellyfin 10.10.7+ or 10.11.x (ideally, 10.11.11) before upgrading! If you are not, the upgrade will fail. Ensure you upgrade to one of these versions first!
Note: The initial load of Jellyfin 12.x will run a few migrations and will take several minutes. Please be patient and do not interrupt the process. You can leverage the (newly improved!) startup UI on your local network to see specific progress, or off-network to see general progress, by visiting the server URL in your web browser during startup.
Note: If you install the RC, you should disable all external plugins and reinstall using the unstable plugin repository, or plugins may fail to load and cause unintended side effects.
This preview release is distributed in all our traditional forms, though not automatically via our Apt repository or latest tag.
12.0-rc3 or preview tags.v12.0-rc2)README.md by @kaunkrishna in #17382Full Changelog: v12.0-rc2...v12.0-rc3
We are pleased to announce the third release candidate preview release of Jellyfin 12.0!
This is a preview release, intended for those interested in testing 12.0 before it's final public release. We welcome testers to help find as many bugs as we can before the final release.
As always, please ensure you stop your Jellyfin server and take a full backup before upgrading!
Starting with this release, we are dropping the preceding 10. from our versioning. Thus, 10.11.x -> [10.]12.x = 12.x. The reason is simple: at this point in the project, we don't envision a hard break in the API like we planned way back in the early days, and this version scheme was causing a lot of confusion amongst users about what a "major" release was. For more information, please see the RC1 release notes.
The main goal of this release has been performance. 10.11.0 dropped a major backend rewrite, and while it was broadly functional, it had a lot of rough edges. This release seeks to polish out most of those rough edges and bring better performance to all users.
There are many other small fixes, improvements, changes, and translations. See our draft release notes here or below for the full list of pull requests. You can also view the Server side changelog here.
Note: You must be on Jellyfin 10.10.7+ or 10.11.x (ideally, 10.11.11) before upgrading! If you are not, the upgrade will fail. Ensure you upgrade to one of these versions first!
Note: The initial load of Jellyfin 12.x will run a few migrations and will take several minutes. Please be patient and do not interrupt the process. You can leverage the (newly improved!) startup UI on your local network to see specific progress, or off-network to see general progress, by visiting the server URL in your web browser during startup.
Note: If you install the RC, you should disable all external plugins and reinstall using the unstable plugin repository, or plugins may fail to load and cause unintended side effects.
This preview release is distributed in all our traditional forms, though not automatically via our Apt repository or latest tag.
12.0-rc3 or preview tags.v12.0-rc2)assign-in expression by @timreichen in #7073Full Changelog: v12.0-rc2...v12.0-rc3
The Stable channel has been updated to 150.0.7871.181/.182 for Windows and Mac and 150.0.7871.181 for Linux, which will roll out over the coming days/weeks. A full list of changes in this build is available in the Log
Security Fixes and Rewards
Note: Access to bug details and links may be kept restricted until a majority of users are updated with a fix. We will also retain restrictions if the bug exists in a third party library that other projects similarly depend on, but havenβt yet fixed.
This update includes 12 security fixes. Below, we highlight fixes that were contributed by external researchers. Please see the Chrome Security Page for more information.
[$500][527930356] High CVE-2026-16420: Type Confusion in WebAudio. Reported by Found by XBOW and triaged by Brendan Dolan-Gavitt on 2026-06-26
[$500][528276487] High CVE-2026-16421: Inappropriate implementation in WebAudio. Reported by Found by XBOW and triaged by Brendan Dolan-Gavitt on 2026-06-26
[N/A][517359779] High CVE-2026-16413: Out of bounds write in ANGLE. Reported by Google on 2026-05-28
[N/A][517651910] High CVE-2026-16414: Insufficient validation of untrusted input in Chromecast. Reported by Google on 2026-05-28
[N/A][519244446] High CVE-2026-16415: Insufficient validation of untrusted input in Extensions. Reported by Google on 2026-06-02
[N/A][520172356] High CVE-2026-16416: Integer overflow in Chromecast. Reported by Google on 2026-06-05
[N/A][521491024] High CVE-2026-16417: Uninitialized Use in Skia. Reported by Google on 2026-06-08
[N/A][522125255] High CVE-2026-16418: Stack buffer overflow in V8. Reported by Google on 2026-06-10
[N/A][523435970] High CVE-2026-16419: Out of bounds read and write in ANGLE. Reported by Google on 2026-06-13
[N/A][533515002] High CVE-2026-16422: Insufficient validation of untrusted input in Certificate. Reported by Google on 2026-07-10
[N/A][534582496] High CVE-2026-16423: Use after free in UI. Reported by Google on 2026-07-14
[N/A][534858939] High CVE-2026-16424: Use after free in GPU. Reported by Google on 2026-07-14
We would also like to thank all security researchers that worked with us during the development cycle to prevent security bugs from ever reaching the stable channel.
Many of our security bugs are detected using AddressSanitizer, MemorySanitizer, UndefinedBehaviorSanitizer, Control Flow Integrity, libFuzzer, or AFL.
Interested in switching release channels? Find out how here. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.
Daniel Yip
Google Chrome
Important
If you are using Part-DB it would be helpful if you fill out this short survey on your usage of Part-DB (Google Forms): https://forms.gle/Q15twx3YYq3qCNfe8
TRUSTED_HOST value must not be quoted in docker-compose file, both in documentation and messages (#1453)Full Changelog: v2.13.3...v2.13.4