MythTV users: help others upgrade!

[yngwin]

As indicated in [bug=299222]bug 299222[/bug], the MythTV package has a non-trivial upgrade from earlier versions to version 0.22 (currently in testing). As the current stable version is about to be masked along with all remaining Qt3 packages, users will need to upgrade to version 0.22. Several users have advised that upgrade instructions are needed, as the upgrade could lead to irreparable database corruption. But the maintainer has said he has no time for this.

Which is why the Qt team is asking for your help. As users, you know how this application works, so please help out other users, who are now still using the stable version, with clear instructions on how to upgrade to version 0.22.

If we cannot offer some sort of upgrade guide to current stable users, we see no other choice than to mask all mythtv ebuilds.

Edit by beandog: Stickied

[depontius]

The biggest issue with the upgrade from mythtv-0.21 to mythtv-0.22 is the database encoding. This issue has been lurking behind the scenes for years, and finally with mythtv-0.22 they're fixing it correctly, once and for all. Unfortunately because of this, existing databases may be considered "corrupt" to some extent or other, and it can cause significant pain in upgrading.

The stuff below worked for me on Sunday. Please feel free to comment or correct. If I made any outright errors, I'll fix my text. Sometimes my wording isn't the best, either. I'll try to fix that if I can, too. Or if someone has had success and wants to rework this, feel free.

The most definitive document on fixing the database is here: http://wiki.mythtv.org/wiki/Fixing_Corr ... e_Encoding
However, if you've been running mythtv under Gentoo for several years, and have ever followed a news/forum entry to "fix your database", which I did a year or two back, you may also have the dread "partial corruption", which is worse than the "equal corruption" they talk about in the guide. I also had my daughter's Ubuntu machine connected as a frontend to my Gentoo mythbackend, and that may have injected character set encoding problems, in itself. The main "Fixing Corrupt Database Encoding" document refers to a mailing list thread for fixing partial corruption here: http://www.gossamer-threads.com/lists/m ... 111#406111 I must caution you that there is a missing flag in the instructions, and my first attempt at the fix/upgrade didn't go well. (more on that later)

I also started another thread on the forums, largely about this issue : http://forums.gentoo.org/viewtopic-t-81 ... ight-.html In that thread, tld furnishes a few scripts that basically perform the same database checks that the mythtv upgrade does, and tells you if your headed for trouble, or not. The scripts told me that I was likely in trouble, and that proved to be true.

So for my brief suggested directions :
1 ) Read the "Fixing Corrupt Database Encoding" document.
2 ) Backup. Backup. Backup. Can't stress this enough. Backup. (see note 1 below)
3 ) Run the checks they suggest to see if your server is properly configured. (see note 2 below)
4 ) Assuming you're misconfigured, follow their instructions for fixing it.
5 ) Run tld's script to look for problems. IMHO the most serious problems are with the "recorded" table, because that can affect your ability to access those gigabytes of data that you've already recorded. I used nuvexport to get my most important stuff out of mythtv, not that I wanted to lose any of it. In particular, 2 of my "recorded" shows were flagged by tld's scripts, and I was careful to get those 2 out of there.
6 ) Assuming you're clean to tld's script, and assuming you followed step #4 above, you should be good to upgrade.
7 ) Run "quickpkg mythtv" (and any other mythtv packages necessary) in case you have to drop back. I did.
8 ) Shut down mythbackend, upgrade the software.
9 ) Run "mythtv-setup" and it will upgrade your database.
10 ) Assuming this went well, start your backend up again, count your blessings, and quit reading.

Since you got here, I'll assume that either you either failed the checks in tld's script, or your mythtv database upgrade failed. Reread the "Fixing Corrupt Database Encoding". Follow the "Database Backup and Restore" link and read that, pay special attention to the "Partial Restore" section. Follow the mailing list link under the "Partial vs "equal" Corruption" section and read that. I got my system to upgrade properly by following the mailing list instructions, with one key exception, on Step 4. The original Step 4 is missing the "--partial_restore" flag. My first attempt failed to upgrade. On my second attempt, I added that flag and it succeeded. I've quoted the steps below, adding the flag.

Code: Select all

1) Back up your database (
http://www.mythtv.org/wiki/Database_Backup_and_Restore )

mythconverg_backup.pl


2) DROP your old database:

cat << "EOF" | mysql -umythtv -p mythconverg
DROP DATABASE IF EXISTS mythconverg;
CREATE DATABASE IF NOT EXISTS mythconverg;
ALTER DATABASE mythconverg DEFAULT CHARACTER SET latin1;
EOF

(and, no, the "latin1" is not a typo or a mistake, and, no, the "latin1"
won't cause any issues for users with non-latin characters).

3) Do a complete restore of the blank MythTV 0.21-fixes database:

mythconverg_restore.pl --dir=$HOME --file=mythconverg-1214-blank.sql
--verbose

4) Do a partial restore of your backup (fix the filename and directory
as appropriate):

mythconverg_restore.pl --partial_restore --dir=$HOME
--file=mythconverg-1214-20091105184542.sql.gz --verbose

5) Run the 0.22rc or 0.22-fixes or trunk mythtv-setup . It should
successfully upgrade your database. You will then have to reconfigure
MythTV (all of mythtv-setup configuration and all of mythfrontend
settings) and your plugins. (And, on the bright side, having to redo
your settings means that you will get to go through all the settings
that have been added since you first configured and set them the way you
really want them. :)

Note1 : There are 2 ways to back your database. The "official" way is with the mytconverg_backup.pl script. I recommend using it. The "fast" way is with "cp -a". Shut down mysql, (/etc/init.d/mythbackend stop ; /etc/init.d/mysql stop) go to /var/lib and "cp -a mysql mysql-bkup". You can then start mysql again. Make sure it's stopped any time you use this method to shuffle the database. I used both methods. The "cp -a" method seems faster and less intrusive to me, but I always used the mysqldump, as well.

Note2 : Your probably better off if you find that your database is misconfigured. That makes it more probably that you have "equal corruption", which is more easily fixed. I had done this fix a year or two back, prompted by either a forum or announcement. Then later I found that my.cnf had gone back to utf8, which I believe caused the partial corruption. I don't know if /etc/mysql wasn't properly protected from etc-update, or if I just missed it. But once it went back, mythtv started shoving utf8 stuff into my latin1 database.

[ricklous]

I moved from stable to unstable in order to get 0.22 when it appeared in portage. As i'd not run unstable before, I took a full copy of my system drive before doing anything emerge-y.

Apologies if this is sucking eggs to the majority of readers, my myth box was the first venture into the world of gentoo and so everything ive done with it has been somewhere on the learning curve for me, and the jump to an 'unstable' 0.22 was probably the biggest. Even if .22 now makes it to stable, a full backup is probably a good thing to do for peace of mind. If anyone has better suggestions to how i did this or thinks something isnt clear enough, feel free to mention it.

Anyway, on with my contribution:

I already had a spare partition the same size as the system partition and this process was a lot simpler with the recordings being on a separate partition from the system one.

This is the process i used:

Make a mountpoint for the 'spare'

Code: Select all

mkdir /mnt/sandbox

mount the spare partition ( which for me was sda6) at the new mountpoint:

Code: Select all

mount /dev/sda6 /mnt/sandbox

shutdown mythbackend to prevent data changes during the copy:

Code: Select all

/etc/init.d/mythbackend stop

then do the actual copy operation:

Code: Select all

cp -ax / /mnt/sandbox

once the copy has completed, edit the fstab within the copy so it can boot correctly:

Code: Select all

nano /mnt/sandbox/etc/fstab

depending on your current config theres one or two lines you need to edit. Below is my original:

Code: Select all

/dev/sda1       /boot           ext2    defaults,noatime     1 2
/dev/sda2       none            swap    sw                   0 0
/dev/sda5       /               ext4    noatime              0 1
/dev/sda7       /mnt/big        ext4    defaults,noatime        0       0

which needed to be changed to:

Code: Select all

/dev/sda1       /boot           ext2    defaults,noatime     1 2
/dev/sda2       none            swap    sw                   0 0
/dev/sda6       /               ext4    noatime              0 1
#/dev/sda7       /mnt/big        ext4    defaults,noatime        0       0

The changes are to remap the root mountpoint to the new partition, and to comment out the partition that has all the media on it. Although this will confuse the 'sandbox' myth install initially when you boot into it, because it wont be able to find the media, it also prevents the sandbox install from touching the media to do things like autoexpire recordings and so on. Later on, you can give it a location within the sandbox partition to save media. As this is just a partition for a backup or test-run upgrade, it doesn't need more that a few GB to test recordings and so on.

Even though /dev is populated by udev later on, you need to create the console entry. If not, you will receive the error "unable to open initial console".

Code: Select all

mknod /mnt/sandbox/dev/console c 5 1

The next step is to edit the boot configuration:

Code: Select all

nano /boot/grub/menu.lst

which on my box was initially:

Code: Select all

default 0
timeout 3
splashimage=(hd0,0)/grub/splash.xpm.gz

title MythTV
root (hd0,0)
kernel /kernel-2.6.32-gentoo-r5 root=/dev/sda5

And i changed it to:

Code: Select all

#default 0
timeout 3
splashimage=(hd0,0)/grub/splash.xpm.gz

default saved
fallback 0 2


title MythTV
root (hd0,0)
kernel /kernel-2.6.32-gentoo-r5 root=/dev/sda5
savedefault

title Sandbox
root (hd0,0)
kernel /kernel-2.6.32-gentoo-r5 root=/dev/sda6
savedefault 0

So, roughly speaking, i created a duplicate entry titled Sandbox and pointed that at the new partition. The 'default saved' option means that I can run 'grub-set-default 0' to tell grub i want the first kernel/system booting when i restart and running 'grub-set-default 1' tells grub I want the sandbox system next time i boot. The line 'savedefault' in the first kernel config tells grub that while im running my 'real' system, if i don't run 'grub-set-default 1' before the next boot, i want that first config again. conversely, the line 'savedefault 0' in the sandbox config tells grub that once ive booted into the sandbox, I want it to switch to the first config on the next reboot unless i specifically run 'grub-set-default 1'. this means if ive cocked something up and the sandbox won't boot, you just need to reset the system and the first system will boot instead of the sandbox. Really useful when you're running the box headless. I hope I've explained that well enough...

Last thing to do is set confirm your duplicate system runs fine:

Code: Select all

grub-set-default 1
shutdown -r now

Which sets grub to run the sandbox config when it reboots, and then reboots the pc.

What should happen, is that an identical system boots up, running from the 'sandbox' partition. You now have two options:

1) do the emerge/updates on the sandbox, see what trips up and work out your fixes while you're using the sandbox so you know how to prepare yourself when you do the upgrade to your 'real' system. if you do this you need to run mythtv-setup on the sandbox system and give it somewhere local to the sandbox partition to store your media as your media partition shouldn't be mounted and myth will have nowhere to save test recordings etc.

2) do the updates on the real system, knowing that if anything goes wrong you can reboot into the sandbox and wipe your messed up real system and copy the sandbox system back to the real system partition and get up and running again.

Personally, route 1 was my prefered option as it kept my media away from my tinkering while i was doing a test run.


some notes:

a) Mine is a one-box system. I'm assuming if you've got a myth network that as long as your other boxes arn't running when you fire up the sandbox then they will be fine, but dont quote me.

b) the only other major hurdle (or, steep learning curve) that i found when i switched from 0.21 was that I hadn't appreciated the whole qt3-to-chunks-of-qt4 jump going on. I got myself in a right tangle with blockers etc and ended up unemerging qt3 and other stuff before emergeing mythtv would pull in qt4 and tidy everything up for me. im guessing this is a lot simpler now qt4 things are stable, could 'those that know' confirm this?

c) During my update lirc got updated as well, and my remote, a microsoft media centre one, stopped working. It turned out that the mceusb2 driver has been rolled into the mceusb driver, and the use flags need changing accordingly.

Hope this is helpful.

EDIT: inserted recreation of /dev/console in sandbox partition

[Nicias]

Followed the upgrade guide, no problems with mythtv or mythvideo.

However, my mythtv over lighttpd has stopped working. I get this message now:

Code: Select all

Warning at /var/www/localhost/htdocs/mythweb/modules/_shared/tmpl/_errors/db_vars_error.php, line 23:
require(modules/_shared/tmpl/tmpl/header.php) [function.require]: failed to open stream: No such file or directory

Fatal error: require() [function.require]: Failed opening required 'modules/_shared/tmpl/tmpl/header.php' (include_path='.:/usr/share/php5:/usr/share/php') in /var/www/localhost/htdocs/mythweb/modules/_shared/tmpl/_errors/db_vars_error.php on line 23

[depontius]

Followed the upgrade guide, no problems with mythtv or mythvideo.

However, my mythtv over lighttpd has stopped working. I get this message now:

Code: Select all

Warning at /var/www/localhost/htdocs/mythweb/modules/_shared/tmpl/_errors/db_vars_error.php, line 23:
require(modules/_shared/tmpl/tmpl/header.php) [function.require]: failed to open stream: No such file or directory

Fatal error: require() [function.require]: Failed opening required 'modules/_shared/tmpl/tmpl/header.php' (include_path='.:/usr/share/php5:/usr/share/php') in /var/www/localhost/htdocs/mythweb/modules/_shared/tmpl/_errors/db_vars_error.php on line 23

I seem to remember seeing somewhere that the USE flag requirements for mythweb have changed. I'm sorry I can't be more specific, other than to remember that the flag that changed in one of the dependent packages was "json". This might not be your problem, but maybe it is.

[Nicias]

I read that too, and I have +json in my make.conf.

[tld]

Followed the upgrade guide, no problems with mythtv or mythvideo.

However, my mythtv over lighttpd has stopped working. I get this message now:

Code: Select all

Warning at /var/www/localhost/htdocs/mythweb/modules/_shared/tmpl/_errors/db_vars_error.php, line 23:
require(modules/_shared/tmpl/tmpl/header.php) [function.require]: failed to open stream: No such file or directory

Fatal error: require() [function.require]: Failed opening required 'modules/_shared/tmpl/tmpl/header.php' (include_path='.:/usr/share/php5:/usr/share/php') in /var/www/localhost/htdocs/mythweb/modules/_shared/tmpl/_errors/db_vars_error.php on line 23

That's an odd one. It looks like your template isn't being defined or may be improperly set. The template name it's using is a literal 'tmpl' and the only valid templates are default, iPod, lite, or wap. There may be a bad value of some sort in the database table that stores the session. I'm not clear which template your supposed to be using, but it appears you can force a reset to any one by browsing to your mythweb server using:

Code: Select all

http://<your_server>/mythweb?RESET_TMPL=default

...replacing 'default' with whatever template you're supposed to be using.

Tom

[Nicias]

hmm, my thought was that it wasn't getting my default template, because it couldn't log into my database, because I'm using lighttpd and I have to patch the database.php file to get that login-info. Added that patch back in, and it works like a charm.

[zfc-tinkerer]

I followed the upgrade instructions on this thread. I had partial corruption (not surprising when the database is 5 or 6 years old!). Now myth still complains of corruption when I try to upgrade the database, but when I rerun the script I get a very short list of problems. Is there a kind person who could walk me through fixing these few lines manually? Here's all the output of the test script:

Testing people...
Testing recorded...
Warning 1366 Incorrect string value: '\xE3o Pao...' for column 'description' at row 148
Testing oldrecorded...
Warning 1366 Incorrect string value: '\xE2t\xE9 \xE1 ...' for column 'description' at row 61
Warning 1366 Incorrect string value: '\xE2t\xE9 \xE1 ...' for column 'description' at row 1544
Warning 1366 Incorrect string value: '\xE9s) in...' for column 'description' at row 2270
Warning 1366 Incorrect string value: '\xE3o Pao...' for column 'description' at row 2947
Warning 1366 Incorrect string value: '\xE3o Pao...' for column 'description' at row 3059
Warning 1366 Incorrect string value: '\xE3o Pao...' for column 'description' at row 3062
Testing oldprogram...
Failures detected on 2 tables

Thanks in advance.

[flysideways]

If we cannot offer some sort of upgrade guide to current stable users, we see no other choice than to mask all mythtv ebuilds.

NOOOOO!!!!!!!

I was feeling adventurous so I updated to .22 on my mythbox that has run 24/7 for many years. I only update that box every 6 to 9 months. The update worked flawlessly, just followed the instructions.

[rich0]

If we cannot offer some sort of upgrade guide to current stable users, we see no other choice than to mask all mythtv ebuilds.

NOOOOO!!!!!!!

Not to worry - mythtv-0.22 is stable now (well, not on ppc yet), so x86/amd64 users don't have to worry about this.

I imagine that we'll remove 0.21 for good when qt3 is removed. It is already masked. Anybody migrated to 0.22 shouldn't notice anything unusual once they get past the upgrade process.

[flysideways]

zfc-tinkerer

Have you looked at the adjacent entries? Maybe the differences from the non-corrupt entries are obvious. Posting some of the examples of corrupt and adjacent non-corrupt entries might be helpful.

If you have never wandered about in mysql databases this gentoo doc provides a quick overview of how to use your mysql database.

I have used the docs from the mysql website extensively in the years gone by and found them very helpful.

I am not one to point anybody at the docs as an answer but am presently short on time and know how frustrating a non-working mythtv can be.

Maybe someone else has actually had to correct their entries manually and can help?

[zfc-tinkerer]

Thanks, that, together with google and a bit of stubborn trial and error, got things working. Not sure what I thing of the new default theme, but now we can watch our shows.

[tld]

After upgrading I went with the Mythbuntu theme (I'm using it it widescreen). I'm pretty happy with that.

I was impressed that there was an OSD theme available (BlackCurves-OSD) that was actually friendly to my RPCRT TVs overscan...too cool. In 0.21 I was constantly hacking the OSD xml files so as not to chop off the playback menu etc.

[depontius]

Has anyone else used "nuvexport" successfully since upgrading to 0.22? I'm having a pile of problems, the maintainer/developer is in touch with me, and I'm trying to put together a consistent picture for him.

As best as I can tell, I can export a show that was recorded prior to the 0.22 upgrade, but not one recorded after. There are other problems, in that once an attempt to export has failed, nothing works without rebooting. I obviously haven't scoured /tmp well enough, or perhaps it's hiding something somewhere under /var, or some such. Makes debugging a bear, when problems become sequence dependent. The best I can see is that the audio parameters eg -"-e 48000,16,2" for a "pre" recording, vanish "-e ,," for a "post" recording.

I've torn apart an ascii dump of the database, and can't find differences between pre and post episodes, other than the obvious ones of title, date, etc.

I just figured I'd see if anyone else is having similar experiences. By the way, I have a newer (20100301) snapshot and have tweaked the ebuild to use it, AND install with mythtv-0.22. Nobody has told me this won't work, and the myth pages are advertising nuvexport as part of the 0.22 release.

[rich0]

I'm not sure if it is supposed to work, but in portage nuvexport depends on mythtv-0.21 and is masked as a result. A 0.22 user can't even install it without overriding this.

If you find out that there is a version that works with 0.22 let us know (feel free to file a bug) and we'll see if we can get it into portage.

[depontius]

That's all I really did - take the portage ebuild, tweak it to point to newer tarballs, change the 0.21* to 0.22*, and go. Of course it doesn't work, but as I said, someone is working with me on that. The immediate problem appears to be that it can't pick up the audio parameters on stuff recorded with 0.22.

Here's a quick experiment for anyone who uses an ivtv-type card and puts recordings into MythTV's media directory with a filetype of ".mpg". (I have Hauppauge hvr-1600, which isn't ivtv, but it still has the same sort of hardware mpeg.)

Use mplayer or smplayer to play a recording directly out of MythTV's media directory. I find that this works just fine with recordings made with 0.21, but for recordings made with 0.22, there is no sound. Yet when I play those recordings with Myth, the sound is just fine. Something is odd, I haven't much idea what it is, but it appears to be a configuration issue. My first guess was mp3 vs ac3 for sound, but from what I can tell, mplayer should be able to seamlessly handle both.

[mbrehon]

depontius, I just tried your experiment and it kinda worked ok here. I say kinda because I'm recording and playing back on different machine/arch. My recording machine is nearly 5yrs old, soon to be decommissioned and the sound is horked for the last couple of months (can't get sound from any other app after mythfrontend has been started), so I copied the file to my soon to be backend and was able to play it back there just fine with sound.

info:
running mythtv 0.22 since late last year, started out on 0.18.
playing back a video recorded this morning from a pvr-500.

recording machine (x86):

Code: Select all

# uname -a
Linux mythbox 2.6.31-gentoo-r10 #2 PREEMPT Sat Mar 13 18:23:52 MST 2010 i686 Unknown CPU Typ AuthenticAMD GNU/Linux

playback machine (x86_64):

Code: Select all

$ mplayer 1007_20100320052900.mpg 
MPlayer SVN-r30554-4.3.4 (C) 2000-2010 MPlayer Team

$ uname -a
Linux vienna 2.6.31-gentoo-r10 #2 SMP PREEMPT Sun Mar 14 11:00:35 MDT 2010 x86_64 AMD Athlon(tm) Dual Core Processor 5050e AuthenticAMD GNU/Linux

I may reboot the recording machine tomorrow morning then try mplayer before launching mythfrontend and let you know what happens to be just a little more thorough.

-M

[depontius]

As I said, I've been getting some developer/maintainer help. On his last posting, he suggested adding the "-demuxer lavf" to the mplayer command line. That works for making the 0.22-recorded stuff work with sound, though there's quite a bit of hate-mail coming out as it runs.

I currently believe that this has something to do with improperly filled recording profiles. I began using MythTV back around 0.19, with a bttv-based card. I did a fair amount of fiddling with recording profiles to fine-tune my storage requirements and get rid of some annoying AC97 audio aliasing problems. When I got my hvr-1600 cards I did further playing, because their compression was so much better out-of-the-box that I bumped their quality level up by default, because I could. After migrating to 0.22 - with the partial corruption problems, I did nothing at all with the recording profiles. I now believe that this is the problem, but am not sure how to get out of it, both for nuvexport of old recordings and better quality of new.

[depontius]

I believe the problems with nuvexport have been solved.

When I moved from 0.21 to 0.22 I had to fix "partial corruption" in my database. Basically that lost everything except my recording information, and even a little bit of that. (The shows that character set ambiguities messed up.) I never touched my recording profiles, and they had NULL for both audio and video codec identifiers. Recordings happened OK, and MythTV could play them OK, but there was something in there messed up, and it gave nuvexport fits. With help, I managed to get things running, but even then it ran transcoding at a bit under half-speed compared to what it had under 0.21, and failed 97% through the first pass. (That happens sometimes, and usually works on a second try.)

I simply walked through all of the recording profiles, accepting the defaults. Good values got put into the database, and all appears to be well. I've tested a new recording using mplayer, and the bad signatures are gone. I haven't actually used nuvexport yet, but there's something on tomorrow I want to grab, so I'll try it in a few days.

Oh yes, nuvexport should "just work" with 0.22. I believe you could simply change the dependence to >=mythtv-0.21* instead of =mythtv-0.21*. But there is also a new snapshot out - 20100301, so if you're touching an ebuild you may as well pick up the newest stuff.

[andrewwalker27]

Just a quick heads up for anyone who is interested.

MythTV 0.24 Available

No ebuilds available yet though.

[link1305]

Yup, I'm eagerly awaiting the ebuilds

[FizzyWidget]

After updating from mythtv 0.22 to 0.23 (i know 0.24 is out but like others im waiting on ebuilds) mythweb throws up the error

Code: Select all

Fatal error: Call to a member function query_col() on a non-object in /var/www/localhost/htdocs/mythweb/modules/backend_log/init.php on line 19

Anyone have an ideas on how to fix this? I googled a bit and looked on a few mailing lists and have tried all they suggested on there, but with no luck

[tld]

After updating from mythtv 0.22 to 0.23 (i know 0.24 is out but like others im waiting on ebuilds) mythweb throws up the error

Code: Select all

Fatal error: Call to a member function query_col() on a non-object in /var/www/localhost/htdocs/mythweb/modules/backend_log/init.php on line 19

Anyone have an ideas on how to fix this? I googled a bit and looked on a few mailing lists and have tried all they suggested on there, but with no luck

That sounds like an error you'd get if you weren't getting a database connection. In my case (as was the recommended setup if I remember correctly) I have a symlink in /etc/apache2/modules.d/ (in my case it's named mythweb.conf) that links to /var/www/localhost/htdocs/mythweb/mythweb.conf.apache. That has setenv statements starting at line 63 that define the database connection stuff.

By the way. I see that MythTV is switching from svn to git. I wonder if that's going to affect the ebuilds. If I remember however I think the gentoo ebuilds get their archives via the MythTV trac system, which they are going to continue to use.

Tom

[FizzyWidget]

Forgot to add that i am using lighttpd, and i have a symlink to the correct config file, and i have also checked the username and password are correct, cant really look into it now as im visiting relatives and am out of state for the next 3 months, so i guess it will have to wait