Latest Posts
Forum: Windows 8: Media Center & OS
Last Reply: saxnix (May 22 2013 05:17 PM)
Forum: Windows Media Center Plugins & Addons
Last Reply: makryger (May 22 2013 03:58 PM)
Forum: Pay TV Configuration - Foxtel : Optus : Austar
Last Reply: philzgr8 (May 22 2013 03:49 PM)
Forum: Media Center & Technology News
Last Reply: logifuse (May 21 2013 11:22 PM)
Recent Topics
-
My Channel Logos XL!makryger - May 22 2013 03:58 PM
-
Credit Card Fraudlogifuse - May 22 2013 01:06 AM
-
Live TV on the Xbox Oneipguy - May 21 2013 10:33 PM
-
Xbox One and TVipguy - May 21 2013 03:17 PM
-
Dynamic DNS serviceDuffy - May 21 2013 05:55 AM
Resume Problems
#1
Posted 01 May 2012 - 07:12 AM
I am in the process of moving moving my mythbuntu onto some newer hardware and all is going well. Just have a couple of issues with the whole shutdown/resume problem...
When I resume and go to watch live tv I get an error message.
"You should have received a channel lock by now. You can continue to wait for a signal, or you can change the channel with the Up or Down, Chance Video Source"
I recall someone else on this forum having the same sort of issue with the tuner locking up by can't for the life of me remember what post it was in..
Has anyone else had this issue on resume?
I am currently running a combined FE/BE on the latest version of Mythbuntu 12.04.
Thanks
Peter
#2
Posted 01 May 2012 - 07:51 AM
1 Rather than using suspend if you use acpi wakeup the problem will disappear however system up times will be much slower as it will be from a cold boot and your remote wont be able to wake up your system.
2 Mythtv users irc channel wagnerp linked me to this and it worked well with a dvico receiver that like to change on resume for me You might find this works. Its in c and needs to be compiled and you need to find which port your tuner is plugged in on.... If its usb of course!
Alan Sternhttp://marc.info/?l=...59435621262&w=2
this looks right... http://mark.info/?l=...59435621262&w=2
<wagnerrp> i would just put that at the end of my standby script
<wagnerrp> so when it came out of standby, that was the next function called
> From writing USB device firmware, I know the devices I worked with had
> no way to transition from the configured state to the "waiting for
> address to be assigned" except if the device was physically reset by
> loosing power. So I would be very supprised if many devices could do
> this any other way.
For what it's worth, I have never seen or heard of a USB device that
would not go into the "default" state (i.e., waiting for an address to
be assigned) after a port reset -- unless its firmware had already
crashed. When that happens, all you can do is a power cycle.
In answer to Meher's question: Yes, there is a way to force Linux's USB
stack to perform a port reset and re-enumerate a device. It can be
done using usbfs; I have attached a C program to carry it out. Note
however, that reset followed by re-enumeration is _not_ the same thing
as power-cycle followed by reconnect and re-enumeration.
["usbreset.c" (TEXT/PLAIN)]
/* usbreset -- send a USB port reset to a USB device */
#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <errno.h>
#include <sys/ioctl.h>
#include <linux/usbdevice_fs.h>
int main(int argc, char **argv)
{
const char *filename;
int fd;
int rc;
if (argc != 2) {
fprintf(stderr, "Usage: usbreset device-filename\n");
return 1;
}
filename = argv[1];
fd = open(filename, O_WRONLY);
if (fd < 0) {
perror("Error opening output file");
return 1;
}
printf("Resetting USB device %s\n", filename);
rc = ioctl(fd, USBDEVFS_RESET, 0);
if (rc < 0) {
perror("Error in ioctl");
return 1;
}
printf("Reset successful\n");
close(fd);
return 0;
}Thats the code
To compile the c code so it will work with linuxcc usbreset.c -o usbresetTo reconnect usb device 3 would besudo ./usbreset /dev/bus/usb/002/003if the tuner is plugged in on /dev/bus/usb/002/003
file is named usbreset
original c code is called usbreset.c
#3
Posted 01 May 2012 - 08:02 AM
I guess you guys don't have the problem since your running a Frontend with dedicated Backend setup...
The Frist option sounds ok but will be annoying if i can't turn it on via the remote.
The TV tuner is a PCI one so i don't even know if the second one will be applicable?
#4
Posted 01 May 2012 - 09:41 PM
option3 You may be able to unload a module prior to suspend and reload after with regard to your pci tuner .. I have no experience of doing this though so dont know if it will help or not. It might be worth looking into. And yes we dont have the problem as most run dedicated backends.
Option 4 would be to buy a remote device that can make and break the power supply to your htpc.
Another again might be a sony playtv although I dont know how they fare with suspend.
#5
Posted 02 May 2012 - 01:47 AM
The problem is in the drivers. Very few, if any, tuner drivers have code to properly suspend their operation during a suspend cycle. So it becomes a manual process for the administrator of the system. But hey, at least you have the option to try and fix it. Have a go at manually unloading a driver before suspend on a Windows machine and you'll appreciate Linux even more!
I used to have a similar setup way back when I first switched to Linux. The only clean way to do it is:
1. Stop myth (So it frees the tuners)
2. Unload the tuner modules
3. Suspend the machine.
Then when coming out of standby:
1. Reload the tuner drivers,
2. Reload myth.
That can all be done. Where the complications arise is because it's Myth itself that determines the idle state etc and usually shuts the machine down. To do the above myth can't be the program that shuts down the machine.
You would need to get myth, in it's shutdown script, to write a variable or create a dummy file somewhere that a second script running in the background notices. That script then takes care of stopping myth, unloading the tuners etc etc. So instead of letting myth shut the machine down, just get myth to tell something else that shutdown time has arrived. By that time myth has done everything it should've, set the timers for next record etc, but instead of calling shutdown and stopping the machines it could just write a file to /tmp called "shutdown".
A second script that runs all the time checking for a file called "shutdown" to appear in /tmp can then stop myth, unload all the modules, and put the machine in standby.
The resume script can then remove the "shutdown" file from /tmp, reload the modules for the tuners, and start up myth.
You just need to find out manually what needs to be done to make a suspend/resume cycle work.
i.e. From the command line try to stop myth, remove the modules, put it to sleep, then wake it up, reload the modules, reload myth, and test that live tv works. Once you can do that manually the process can be automated.
You can find the modules using lsmod.
All versions of linux have the ability to unload/reload modules during suspend/resume. If you are lucky just adding the right modules to the configuration file that handles that might be enough (without stopping myth first), but I'd doubt it. There is a switch in myths configuration something along the lines of "Grab tuners only when needed", which causes myth not to take complete ownership of the tuners all the time, that could help.
You certainly aren't the first person with this issue and won't be the last. Google around for some ideas.
I just remembered that there is another program called "mythwelcome", that is designed to help with some of the issues regarding running a combined box.
The myth wiki entry for it is here. See if that can help.
Cheers,
Arkay.
#6
Posted 09 May 2012 - 04:20 PM














