That is exactly the type of thing the article/video was saying was the problem with existing CVTs. The power transfer is performed by friction, which limited the amount of torque that the system could handle. The NuVinci transfers power through friction with those balls.
That's how the system works. The idea is that however the mechanics work, there is no real load being placed on that lower control shaft, and the secondary motor only need to be strong enough to overcome the friction of the bearings on the sun gear. How well that works in reality, I'm not certain.
Reality is exactly opposite. Induction motors are very efficient through most of their operating range, while internal combustion is really only efficient along a narrow band of RPM, which is typically optimized to be highway cruise speed in high gear. With induction motors, they would merely allow for a much simpler controller, one that does not have to provide variable frequency power output.
Regaular old raid arrays just don't resize like that.
Actually, they do. Nearly every RAID solution I've ever seen will allow you to expand the array to the size of the smallest drive. Increase the size of the smallest drive, the controller automatically rebuilds with the new drive, and then expands the array when complete. Then it's just a matter of going through whatever procedures your file system requires to expand a partition.
If you want to see something that will actually efficiently use disparate sized drives, check out RAID 1E and the file duplication on ZFS and BtrFS. Rather than mirroring two specific drives, these simply contain a pool of drives, and make sure each block or file exists on at least two of the drives.
Plus I recommend the drobo as well with its
cool "Beyond Raid" system that let's you just pull out the smallest
disk in your array and plug in a new one. Anyone who's ever rebuild
or updated a traditional RAID array knows what an improvement that is.
Eh? That sounds like every other RAID system I've ever used.
Completely agree about the settings being categorised - in fact I'd be happier if they were nicely categorised in the database, but as it is they're all just glommed into a single table listed in alphabetical order, without any sort of hierarchical structure in the key names (such as you do with objects in firefox's about:config for example) - wouldn't it be nice to have a frontend.display.widgets.renderer = opengl for instance?
Agree that it's entirely possible I'm doing very complicated things, but this is why I get so annoyed at the bulk of Myth power users; I say something's needlessly complicated, and I'm told it's because Myth is so powerful. If something powerful doesn't work as I'd like it to, I'm told I'm making things needlessly complicated.
Technically, there is no ordering of settings in the database. They are just inserted as needed. If they showed up in alphabetical order, its because you sorted them that way in your select statement. Manual tinkering with settings outside the GUI has never been recommended or supported in any manner.
Almost everyone will agree that there are far too many settings, and that their layout could be handled better. MythTV was designed for, and used on for several years, low resolution standard definition TVs. What works there doesn't make much sense on a higher resolution display. I have to say 'almost everyone', as there has been concerted effort over the past year to clear out bad and unnecessary settings. Every time something would be removed, people would pop into the mailing list and IRC channels bickering about how they couldn't live without their particular pet setting. Nevermind the fact that the setting was no longer even functional, and when it previously did function, enabling it caused bad things to happen.
MythTV does not store the location of recorded shows, all it stores is the base filename, storage group, and hostname. If the recording is in any folder defined as part of that storage group, it will find it. If the recording is in any folder defined as part of any storage group, it will find it. If you want to move your recordings to a different folder, all you have to do is tell MythTV what folder that is, and it won't care.
The only thing you can do that could cause it problems is changing the hostname of your backend server. The backup script provides options for migrating from one hostname to another.
MythTV has full mouse support within the menu. You just have to remember to go into the frontend settings and enable the mouse cursor. It will have full mouse support within the OSD during playback when the new OSD code is merged in prior to 0.24, which is expected late this fall.
Normal DRM rules apply here. Open source projects cannot be licensed to support any form of DRM, as someone can just strip out the code blocking users access to copy-controlled content, recompile, and duplicate at will. Sure, someone could reverse engineer the handshake and decryption, but then we're right back to the whole "DMCA violators are terrorists" issue.
Mythlink.pl is basically just mythrename.pl with the ability to rename recordings removed. Those were intentionally removed as doing so can be dangerous. External editing of the database is not preferred. Renaming a recording while it is in use elsewhere will cause problems. Renaming a recording to one with special characters may cause problems. If you just link to them rather than rename them, you completely sidestep any of these issues.
Could you list any cards that support capture of encrypted HDMI content? They don't exist because the manufacturer would lose their license. We couldn't get an HDCP stream to decrypt even if we wanted to, nevermind the fact that most of the MythTV devs live within the US, where breaking encryption is akin to terrorism.
Nor should MythTV support either of those. The LinuxTV project provides hardware support. MythTV will use (with a couple exceptions) any card supported by one of the V4L, DVB, or IVTV APIs.
Right. It has nothing to do with DRM-related poo flinging. DRM requires the user have the content and the keys, so the only way you can prevent the user from having unauthorized access to the content is through obfuscation. When the code is freely available to open and alter, such schemes simply cannot work.
Apperently not on by default? And hidden away in the darkest corners of MythTV? or added somewhere after 0.22
That type of recording has been available for several years in the form of Multirec. On digital tuners, you can record however many simultaneous streams you want. There was a discussion about the form you want, where it simply duplicates the single stream coming out of the card. Because of the way the recording system is set up, those changes would not be trivial, and the developers have deemed it better to spend their time elsewhere on things they would rather use with MythTV.
As I pointed out in another post, doesn't work at all in the netherlands.
That has everything to do with the fact that the commercial flagger was programmed by someone in the US, with their style of ads. In order to work in the Netherlands, the commflagger would have to be retuned for how your ads behave, which is only going to be done by someone actually living there.
there's still alot of manual text-editing steps involved, for those of us in the UK at least
MythTV has no text files. The only one it uses is a couple lines to point it at the database. Any manual text editing you may need to do is an external dependency, such as LIRC or XMLTV. It's currently in the near term plans to replace the current setup with a web based one through the backend, move the external MySQL database to an embedded one, and export recordings with a portable metadata file for later import. For what its worth, the current devs don't actually want MythTV to be able to import random videos into the recordings screen. That is the purpose of MythVideo.
According to Wikipedia, it was called "flashlight" because the carbon-zinc batteries couldn't deliver current for long, and had to "rest" periodically:
Wait, is this why flashlights in nearly every video game behave this way?
I buy Blu-ray because I can rip the movies and transcode them. Including Avatar.
Why? It takes a huge amount of power to decode that content, and vastly more to re-encode right back into the same format it came from. When you factor in your time wasted, plus the electricity consumed by the transcode, it's simply not worth the dollar or two of hard drive space you're saving.
This is the thing we need to get through to people like you who think DRM has anything to do with preventing internet downloading.
DRM is not intended to do anything about commercial pirates, the ones who sell copies for profit. They will spend the money to get an unencumbered copy of the movie, one way or another. Law enforcement services are for that. DRM is not to prevent release groups from distributing movies online. Again, someone from the community will get a copy somewhere, somehow, and release it to the internet. Lobbyists who push through legislation giving them control over ISPs are for that. DRM exists only to limit the rights of customers who have lawfully purchased the content. It's all about control, and nothing more. They want you to consume the content only in the manner they approve, and make it difficult for the average consumer (95% of their base) to do otherwise.
Certainly there would be governors put on such a thing to prevent too high a light output from physically blinding the driver, but you would render the NV film useless for as long as you were pointing at it.
LO2 and ethanol... you can get frost burn from contact, but neither are particularly dangerous or exotic. Certainly not when compared to stuff like hydrazine and other extremely toxic chemicals commonly used for rocket fuel.
Plus, if merchant ships could defend themselves, they would be safer. Just think what one of these containers could do to a group of Somali pirates! Forget that ridiculous long range sound attack that has already failed and gotten people killed, its high time that merchant ships stop being simple targets.
There are three problems with this. First, many ports do not allow weapons. Of course you could just hide them, but the repercussions of being caught are severe. There's not much use for a merchant who is banned from docking at port.
Second, cruise missiles are EXPENSIVE. You're talking several million for launch facilities, and several more for each missile. That's why the navy is trying to partially replace them with long range rail guns. Price estimates put one container with four missiles to be up to $20M. The missiles would be worth far more than the ships they would be destroying. They would be worth more than the bounty the pirates are asking for. Now certainly there is worth in taking such a hard line, but that worth doesn't show up on a corporate balance sheet.
Third, cruise missiles are long range. If merchants are going to defend themselves, you want them to have positive visual verification of a threat first. Cruise missiles aren't going to work against something a mere half mile out, and you don't want them firing on something a hundred miles out because 'they turned toward us menacingly'.
Slashdot Mirror
That is exactly the type of thing the article/video was saying was the problem with existing CVTs. The power transfer is performed by friction, which limited the amount of torque that the system could handle. The NuVinci transfers power through friction with those balls.
That's how the system works. The idea is that however the mechanics work, there is no real load being placed on that lower control shaft, and the secondary motor only need to be strong enough to overcome the friction of the bearings on the sun gear. How well that works in reality, I'm not certain.
Reality is exactly opposite. Induction motors are very efficient through most of their operating range, while internal combustion is really only efficient along a narrow band of RPM, which is typically optimized to be highway cruise speed in high gear. With induction motors, they would merely allow for a much simpler controller, one that does not have to provide variable frequency power output.
Regaular old raid arrays just don't resize like that.
Actually, they do. Nearly every RAID solution I've ever seen will allow you to expand the array to the size of the smallest drive. Increase the size of the smallest drive, the controller automatically rebuilds with the new drive, and then expands the array when complete. Then it's just a matter of going through whatever procedures your file system requires to expand a partition.
If you want to see something that will actually efficiently use disparate sized drives, check out RAID 1E and the file duplication on ZFS and BtrFS. Rather than mirroring two specific drives, these simply contain a pool of drives, and make sure each block or file exists on at least two of the drives.
Plus I recommend the drobo as well with its cool "Beyond Raid" system that let's you just pull out the smallest disk in your array and plug in a new one. Anyone who's ever rebuild or updated a traditional RAID array knows what an improvement that is.
Eh? That sounds like every other RAID system I've ever used.
Completely agree about the settings being categorised - in fact I'd be happier if they were nicely categorised in the database, but as it is they're all just glommed into a single table listed in alphabetical order, without any sort of hierarchical structure in the key names (such as you do with objects in firefox's about:config for example) - wouldn't it be nice to have a frontend.display.widgets.renderer = opengl for instance?
Agree that it's entirely possible I'm doing very complicated things, but this is why I get so annoyed at the bulk of Myth power users; I say something's needlessly complicated, and I'm told it's because Myth is so powerful. If something powerful doesn't work as I'd like it to, I'm told I'm making things needlessly complicated.
Technically, there is no ordering of settings in the database. They are just inserted as needed. If they showed up in alphabetical order, its because you sorted them that way in your select statement. Manual tinkering with settings outside the GUI has never been recommended or supported in any manner.
Almost everyone will agree that there are far too many settings, and that their layout could be handled better. MythTV was designed for, and used on for several years, low resolution standard definition TVs. What works there doesn't make much sense on a higher resolution display. I have to say 'almost everyone', as there has been concerted effort over the past year to clear out bad and unnecessary settings. Every time something would be removed, people would pop into the mailing list and IRC channels bickering about how they couldn't live without their particular pet setting. Nevermind the fact that the setting was no longer even functional, and when it previously did function, enabling it caused bad things to happen.
MythTV does not store the location of recorded shows, all it stores is the base filename, storage group, and hostname. If the recording is in any folder defined as part of that storage group, it will find it. If the recording is in any folder defined as part of any storage group, it will find it. If you want to move your recordings to a different folder, all you have to do is tell MythTV what folder that is, and it won't care.
The only thing you can do that could cause it problems is changing the hostname of your backend server. The backup script provides options for migrating from one hostname to another.
MythTV has full mouse support within the menu. You just have to remember to go into the frontend settings and enable the mouse cursor. It will have full mouse support within the OSD during playback when the new OSD code is merged in prior to 0.24, which is expected late this fall.
Normal DRM rules apply here. Open source projects cannot be licensed to support any form of DRM, as someone can just strip out the code blocking users access to copy-controlled content, recompile, and duplicate at will. Sure, someone could reverse engineer the handshake and decryption, but then we're right back to the whole "DMCA violators are terrorists" issue.
Mythlink.pl is basically just mythrename.pl with the ability to rename recordings removed. Those were intentionally removed as doing so can be dangerous. External editing of the database is not preferred. Renaming a recording while it is in use elsewhere will cause problems. Renaming a recording to one with special characters may cause problems. If you just link to them rather than rename them, you completely sidestep any of these issues.
Could you list any cards that support capture of encrypted HDMI content? They don't exist because the manufacturer would lose their license. We couldn't get an HDCP stream to decrypt even if we wanted to, nevermind the fact that most of the MythTV devs live within the US, where breaking encryption is akin to terrorism.
Nor should MythTV support either of those. The LinuxTV project provides hardware support. MythTV will use (with a couple exceptions) any card supported by one of the V4L, DVB, or IVTV APIs.
Right. It has nothing to do with DRM-related poo flinging. DRM requires the user have the content and the keys, so the only way you can prevent the user from having unauthorized access to the content is through obfuscation. When the code is freely available to open and alter, such schemes simply cannot work.
Apperently not on by default? And hidden away in the darkest corners of MythTV? or added somewhere after 0.22
That type of recording has been available for several years in the form of Multirec. On digital tuners, you can record however many simultaneous streams you want. There was a discussion about the form you want, where it simply duplicates the single stream coming out of the card. Because of the way the recording system is set up, those changes would not be trivial, and the developers have deemed it better to spend their time elsewhere on things they would rather use with MythTV.
As I pointed out in another post, doesn't work at all in the netherlands.
That has everything to do with the fact that the commercial flagger was programmed by someone in the US, with their style of ads. In order to work in the Netherlands, the commflagger would have to be retuned for how your ads behave, which is only going to be done by someone actually living there.
there's still alot of manual text-editing steps involved, for those of us in the UK at least
MythTV has no text files. The only one it uses is a couple lines to point it at the database. Any manual text editing you may need to do is an external dependency, such as LIRC or XMLTV. It's currently in the near term plans to replace the current setup with a web based one through the backend, move the external MySQL database to an embedded one, and export recordings with a portable metadata file for later import. For what its worth, the current devs don't actually want MythTV to be able to import random videos into the recordings screen. That is the purpose of MythVideo.
but even I am skeptical of a product that is at 0.2x. That says to me its still in early development, is not ready for prime time
If it makes you feel better, you can call it MythTV 23.0.
According to Wikipedia, it was called "flashlight" because the carbon-zinc batteries couldn't deliver current for long, and had to "rest" periodically:
Wait, is this why flashlights in nearly every video game behave this way?
Encryption != compression
Even if the video feed is encrypted with HDCP, it is still raw uncompressed video.
They can, you just need software/hardware which works properly (i.e. x.264 GPU offload engine).
Since when did x264 get GPGPU and decoding capability.
I buy Blu-ray because I can rip the movies and transcode them. Including Avatar.
Why? It takes a huge amount of power to decode that content, and vastly more to re-encode right back into the same format it came from. When you factor in your time wasted, plus the electricity consumed by the transcode, it's simply not worth the dollar or two of hard drive space you're saving.
This is the thing we need to get through to people like you who think DRM has anything to do with preventing internet downloading.
DRM is not intended to do anything about commercial pirates, the ones who sell copies for profit. They will spend the money to get an unencumbered copy of the movie, one way or another. Law enforcement services are for that. DRM is not to prevent release groups from distributing movies online. Again, someone from the community will get a copy somewhere, somehow, and release it to the internet. Lobbyists who push through legislation giving them control over ISPs are for that. DRM exists only to limit the rights of customers who have lawfully purchased the content. It's all about control, and nothing more. They want you to consume the content only in the manner they approve, and make it difficult for the average consumer (95% of their base) to do otherwise.
Napster did this to all of us by demonstrating to the content industries that unprotected media was vulnerable.
Funny that... The DVD spec, complete with DRM in the form of CSS, was finalized in 1995. Napster wasn't released until 1999.
Certainly there would be governors put on such a thing to prevent too high a light output from physically blinding the driver, but you would render the NV film useless for as long as you were pointing at it.
LO2 and ethanol... you can get frost burn from contact, but neither are particularly dangerous or exotic. Certainly not when compared to stuff like hydrazine and other extremely toxic chemicals commonly used for rocket fuel.
Plus, if merchant ships could defend themselves, they would be safer. Just think what one of these containers could do to a group of Somali pirates! Forget that ridiculous long range sound attack that has already failed and gotten people killed, its high time that merchant ships stop being simple targets.
There are three problems with this. First, many ports do not allow weapons. Of course you could just hide them, but the repercussions of being caught are severe. There's not much use for a merchant who is banned from docking at port.
Second, cruise missiles are EXPENSIVE. You're talking several million for launch facilities, and several more for each missile. That's why the navy is trying to partially replace them with long range rail guns. Price estimates put one container with four missiles to be up to $20M. The missiles would be worth far more than the ships they would be destroying. They would be worth more than the bounty the pirates are asking for. Now certainly there is worth in taking such a hard line, but that worth doesn't show up on a corporate balance sheet.
Third, cruise missiles are long range. If merchants are going to defend themselves, you want them to have positive visual verification of a threat first. Cruise missiles aren't going to work against something a mere half mile out, and you don't want them firing on something a hundred miles out because 'they turned toward us menacingly'.