Separate names with a comma.
Discussion in 'TiVo Home Media Features & TiVoToGo' started by smoothtivo, Nov 8, 2005.
No problem...glad to be of help.
OK, I used the command recommended there and it worked. Well, sort of. The links aren't really working properly, but they are there, and I can work with them to make them right.
I'm still having problems though. In the other thread, they mentioned having to edit out the line /etc/rc.d/init.d/functions in the galleon script. There is no such directory, so I commented out the line, but I wonder what it does or rather is supposed to do?
Anyway, if I run galleon, I get the following:
Try `uname --help' for more information
Unable to locate any of the following binaries:
There is a file named wrapper-linux-x86-32 in the directory. If I change its name to wrapper or wrapper-linux--32 it stops complaining about the binaries, but still complains about uname. Grepping for uname in the galleon script brings up:
DIST_OS=`uname -s | tr [:upper:] [:lower:] | tr -d [:blank:]`
DIST_ARCH=`uname -p | tr [:upper:] [:lower:] | tr -d [:blank:]`
DIST_ARCH=`uname -m | tr [:upper:] [:lower:] | tr -d [:blank:]`
Typing "ps -ef | grep galleon" returns a ton of running code, but "galleon stop" claims galleon is not running, and attempts to run gui.sh return a "Could not connect to server" error. Now what?
After nosing around, and checking the uname command on my system, it appears there is no -p for the uname utility under Debian Sarge. There doesn't seem to be a compatible switch for uname at all, so I edited the galleon script and set DIST_ARCH to "i686". It stopped the script from complaining, ofc ourse, but the server still does not appear to be running correctly. The only log file in /var/log/galleon is wrapper.log, and it says repeatedly:
Launching a JVM...
Unable to start JVM: No such file or directory (2)
JVM exited while loading the application.
After 5 failed launches the wrapper exits.
What distro are you using? The galleon script uses the 'uname' command to figure out the architecture of your machine, although as you've seen only one binary for the wrapper is included. It looks like the version of uname your distro has doesn't support all the command-line switches being used in the script.
In some distros, the /etc/rc.d/init.d/functions script just includes some basic functions, but Ubuntu (which was specifically the distro I wrote that HOWTO for) doesn't have that, and it's not really necessary to the galleon init script.
Check the log.txt file under /usr/share/galleon/logs. There might be some helpful information there.
Debian Sarge, as I mentioned before.
That's pretty obvious. After looking at the script I hard coded the variable to x86. 'No change.
Clearly neither does Debian Sarge, and if it isn't necessary that's fine, but something is preventing Java from finding a file.
Check the log.txt file under /usr/share/galleon/logs. There might be some helpful information there.[/QUOTE]
'Not really. As I posted above, the log file just compains the JVM can't find a file. I went into wrapper.conf and changed the log level to DEBUG, but while the amount of text logged jumped drastically, the info about the errored section isn't any mopre specific. It just says:
STATUS | wrapper | 2007/10/28 21:30:40 | Launching a JVM...
ERROR | wrapper | 2007/10/28 21:30:40 | Unable to start JVM: No such file or directory (2)
DEBUG | wrapper | 2007/10/28 21:30:40 | Signal trapped. Details:
DEBUG | wrapper | 2007/10/28 21:30:40 | signal number=17 (SIGCHLD), source="unknown"
DEBUG | wrapper | 2007/10/28 21:30:40 | Received SIGCHLD, checking JVM process status.
DEBUG | wrapper | 2007/10/28 21:30:40 | JVM process exited with a code of 1, setting the wrapper exit code to 1.
ERROR | wrapper | 2007/10/28 21:30:40 | JVM exited while loading the application.
DEBUG | wrapper | 2007/10/28 21:30:40 | JVM was only running for 0 seconds leading to a failed restart count of 1.
DEBUG | wrapper | 2007/10/28 21:30:40 | Waiting 5 seconds before launching another JVM.
How can I figure out which file Java can't find and how do I tell it where to find it?
OK, one more step forward. I found the problem with JVM. The server has to be run as root, but root's path did not have the JRE in it. I added the path to Java to root's path and the error went away.
Now, however, I think I'm having a problem similar to what windracer detailed in the other thread. In my case, however, the system started spooling off log files called log.txt, log.txt.1, log.txt.2, etc. Each one is filled with identical lines which say:
ERROR [ListenThread] ListenThread - java.lang.NullPointerException
If I run the test utility in the GUI, it says something to the effect "No TiVos found on the specified network"
There are four lines in wrapper.log which might be pointing to the issue:
INFO | jvm 1 | 2007/10/28 22:09:08 | Loading native library failed: libwrapper-linux-x86-32.so Cause: java.lang.UnsatisfiedLinkError: no wrapper-linux-x86-32 in java.library.path
INFO | jvm 1 | 2007/10/28 22:09:22 | create table PODCAST_TRACKS (PODCAST_ID integer not null, AUDIO_ID integer, title varchar(255), link varchar(1024), guid varchar(255), description varchar(4096), summary varchar(4096), subtitle varchar(4096), category varchar(255), keywords varchar(255), explicit smallint, block smallint, author varchar(255), publicationDate timestamp, url varchar(255), mimeType varchar(50) not null, size bigint not null, statusinteger not null, duration bigint, rating integer, downloadTime integer not null, downloadSize bigint not null, podcast integer, errors integer, TRACK integer not null, primary key (PODCAST_ID, TRACK))
INFO | jvm 1 | 2007/10/28 22:09:22 | create table VIDEOCAST_TRACKS (VIDEOCAST_ID integer not null, VIDEO_ID integer, title varchar(255), link varchar(1024), guid varchar(255), description varchar(4096), summary varchar(4096), subtitle varchar(4096), category varchar(255), keywords varchar(255), explicit smallint, block smallint, author varchar(255), publicationDate timestamp, url varchar(255), mimeType varchar(50) not null, size bigint not null, status integer not null, duration bigint, rating integer, downloadTime integer not null, downloadSize bigint not null, videocast integer, errors integer, TRACK integer not null, primary key (VIDEOCAST_ID, TRACK))
INFO | jvm 2 | 2007/10/28 22:14:51 | Loading native library failed: libwrapper-linux-x86-32.so Cause: java.lang.UnsatisfiedLinkError: no wrapper-linux-x86-32 in java.library.path
Notice there are two lines which suggest JVM can't find a native library libwrapper-linux-x86-32.so. This smells vaguely like it could be related to the variable DIST_ARCH which I had to hard code in order to get the galleon script to quit complaining. This ultimately points the script to the file wrapper-linux-x86-32. Should I copy this file over somewhere, or is there a line in wrapper.conf to tell Java where to find the library?
The file is actually called libwrapper.so and is under /usr/share/galleon/lib. I'm not sure why yours is now looking for the file with the DIST_ARCH value in the filename there. The line in wrapper.conf that tells it where to find this library is:
# Java Library Path (location of Wrapper.DLL or libwrapper.so)
# Java Library Path (location of Wrapper.DLL or libwrapper.so)
The file in ../lib is libwrapper.so, but the file in .../bin is wrapper-linux-x86-32. It's this file about which the error above complains.
I copied wrapper-linux-x86-32 to the directory pointed to by wrapper.java.library.path.1, and it's working, now. I suspect adding the /usr/share/galleon/lib directory to the PATH variable might work, as well.
Well, I have 2.5 / Linux running, but I cannot seem to transfer back to the TiVos any program which was originally transferred using 2.4. I can start the transfer and begin watching the program, but at some undetermined point in the transfer the TiVo will fail the process. In the To Do History log, it says the recording was not transferred because it was corrupted or longer than reported. I don't know if it is somehow related, but the files also do not show up as having been transfered to the PC in the first place in the Galleon log. Is anyone else having this problem? Is there something special about files transferred under 2.4? I can transfer programs I have authored myself under either version. Right now, however, I have a very large number of programs which are essentially stranded on my file server because they will not transfer successfully.
I was mistaken. It's not just a 2.4 / 2.5 issue. I created a dual version system which can (fairly) easily switch between 2.4 and 2.5. Both are having trouble with various transfers. After some additional testing, I was able to establish that the transfers will often fail no matter which version downloaded them or which version attempted to transfer them back. There are a handful of programs which would not transfer from one particular TiVo to the PC, but when I did an MRV transfer to the other TiVo and then transferred to the PC, it went fine. The programs which are failing to go back to the TiVos are failing long before the end of the program, so I don't think it's a matter of the files being longer than reported. I managed to catch one of the failures when it happend, and the TiVo screen reported there had been a network error, and the transfer would resume momentarily. It never did.
TiVo Desktop doesn't seem to have the same problem. I've transferred several of the same flles which are failing under Galleon without a problem.
It looks like the issue may be large files. Others are also reporting failures with large files. The failure point me be 2.0G.
Well, I had Galleon 2.5.2 working just fine, but now I've managed to break it, and I hope someone can help. I'm moving from a relatively small (500G) system to a 5T+ RAID system. I've upgraded from Debian Sarge to Etch and ironed out most of the wrinkles, but I've managed to kill the Galleon apps I love so much , like Weather, TTG from the TiVo, and Music. TTG from the desktop and TiVo to ComeBack work fine. The good news is I think I've found the problem. The bad news is I don't know how to fix it.
According to wrapper.log, it can't load libwrapper.so because it's 32 bit, but I have an AMD-64 x 2 CPU and I'm running the 64 bit version of Java. How can I either get it to load the 32 bit version or get a copy fo a 64 bit version?
Windracer, do you have any ideas? s2kdave, are you still listening?
Haha, yeah, I'm still listening, just not spending time doing development. Your problem is that there aren't 64 bit binaries for the wrappers that get installed with galleon. You can download the linux version of the java service wrapper and get the 64 bit binary from it and copy it in place.
Thanks. I downloaded the files from the link you sent, but it's still not working. I copied over libwrapper.so, and now there aren't complaints in the log file any longer, but still no apps (oh, and I was mistaken. TiVo to ComeBack isn't working for .TiVo files. It is working for .mpg files). I tried replacing wrapper-linux-x86-32 with the wrapper file in ./bin of the download and renaming it to wrapper-linux-x86-64. The script finds it, and still no complaints, but no apps, either. There is also a wrapper.jar in /lib of the download, so I tried copying it over to /usr/lib/galleon/wrapper-3.2.3.jar, but still no luck. The only other two files which seem to me like possible candidates are ./bin/testwrapper and ./lib/wrappertest.jar. The ./lib/wrappertest.jar is referenced in the sample wrapper.conf file in the download but not specifically in /etc/wrapper.conf.
What else should I try?
Edit: Well I got it working. The details of the ordeal are here.
What's with sourceforge.net? When I try to login to the Galleon site to submit an error report it kicks me out saying my IP is blacklisted. It gives me an e-mail address to contact to help resolve the issue, but when I send e-mail it gets kicked.
Can you get this through to the guy(s) doing the repair work on Galleon?
I really love Galleon's features compared to everything else out there, but there's a serious issue with the Go Back routine. HD programs which get sent back to the S3 TiVo have corrupted video and audio. Every so often the audio will skip usually accompanied by artifacts in the video. It's much worse on some sources than others. I've seen some reports of the same issue running TiVo Desktop, but have not confirmed it myself. Some shows are bad enough to be essentially unwatchable, and it's aggravating even on the programs with the fewest / mildest issues. Here's the thing, however: the very same programs show no artifacts at all when transferred using pyTiVo. Now pyTiVo doesn't handle naming as elegantly as Galleon, but given a choice between a slightly ugly and slightly deficient NPL and corrupted video, I have to go with the clean video and ugly menus, but all in all I'd rather just have Galleon working 100%.
I was able to get in, so I took the liberty of filing the bug for you.
Thanks, windracer. You have been exceedingly helpful, and I don't just mean in this instance.
Could you elaborate?
sorry for not paying attention, real life intervenes.
Any java hackers that want to debug & fix things, send me a PM with your sourceforge account name, sign up for the galleon mailing lists, and I'll coordinate your bug fixing efforts
Sorry for the very late reply. I just spotted this. If you are still interested, I was talking about series name handling. Galleon automatically handles series names. With pyTivo one must create metafiles.