18 minutes ago, plupien79 said:

This docker keeps having issues on updates. The last couple updates, the docker hasn't restarted. No odd messages in the logs. Just notice things haven't been downloading and the the docker went down, updated but never restarted.

Update AutoUpdate if you're using it.

14 minutes ago, Squid said:

Update AutoUpdate if you're using it.

but surely autoupdate updates automatically via autoupdate.....right? 😁 j/k

Just an FYI something is broken with hydra on the 2.6.4 update, the dev isn't sure why it's broken. 2.6.2 seems to be stable.

 

Edit: Looks like 2.6.6 fixes this issue.

Edited May 14, 20197 yr by MowMdown

last update from today won't start up .. get an error 403 or so

 

Edited June 10, 20197 yr by sacretagent

mm restarted docker service and now it works ,.... weird

 

 

I've this weird issue where season searches from within Sonarr will return results from my indexers but they don't get forwarded to SABnzbd. However everything works fine if I search each episode individually using the auto search function. 

 

Any idea why? The logs indicate there were results returned but it's just missing that last step of pushing it to SAB. 

 

The yellow logs are from the manual search.

 

 

Latest update broke hydra2

 

Removed, did fresh install with appdata hydra2 wiped, hydra2 loaded then did a restore backup from file & it's broke again same error: 

 

--------------------------------------------------------------------
SQL State : 42S02
Error Code : 42102
Message : Table "SEARCHRESULT" not found; SQL statement:
ALTER TABLE SEARCHRESULT
ADD indexerSearchEntity INTEGER [42102-199]
Location : migration/V1.21__LINK_SEARCHENTITY_TO_INDEXERSEARCHENTITY.sql (/app/hydra2/file:/app/hydra2/lib/core-2.7.1-exec.jar!/BOOT-INF/classes!/migration/V1.21__LINK_SEARCHENTITY_TO_INDEXERSEARCHENTITY.sql)
Line : 1
Statement : ALTER TABLE SEARCHRESULT
ADD indexerSearchEntity INTEGER

at org.flywaydb.core.internal.sqlscript.DefaultSqlScriptExecutor.handleException(DefaultSqlScriptExecutor.java:253)
at org.flywaydb.core.internal.sqlscript.DefaultSqlScriptExecutor.executeStatement(DefaultSqlScriptExecutor.java:202)
at org.flywaydb.core.internal.sqlscript.DefaultSqlScriptExecutor.execute(DefaultSqlScriptExecutor.java:125)
at org.flywaydb.core.internal.resolver.sql.SqlMigrationExecutor.execute(SqlMigrationExecutor.java:77)
at org.flywaydb.core.internal.command.DbMigrate.doMigrateGroup(DbMigrate.java:367)
at org.flywaydb.core.internal.command.DbMigrate.access$200(DbMigrate.java:54)
at org.flywaydb.core.internal.command.DbMigrate$3.call(DbMigrate.java:284)
at org.flywaydb.core.internal.jdbc.TransactionTemplate.execute(TransactionTemplate.java:74)
at org.flywaydb.core.internal.command.DbMigrate.applyMigrations(DbMigrate.java:281)
at org.flywaydb.core.internal.command.DbMigrate.migrateGroup(DbMigrate.java:246)
at org.flywaydb.core.internal.command.DbMigrate.access$100(DbMigrate.java:54)
at org.flywaydb.core.internal.command.DbMigrate$2.call(DbMigrate.java:164)
at org.flywaydb.core.internal.command.DbMigrate$2.call(DbMigrate.java:161)
at org.flywaydb.core.internal.database.base.Connection$1.call(Connection.java:147)
at org.flywaydb.core.internal.jdbc.TransactionTemplate.execute(TransactionTemplate.java:74)
Caused by: org.h2.jdbc.JdbcSQLSyntaxErrorException: Table "SEARCHRESULT" not found; SQL statement:
ALTER TABLE SEARCHRESULT
ADD indexerSearchEntity INTEGER [42102-199]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:451)
at org.h2.message.DbException.getJdbcSQLException(DbException.java:427)
at org.h2.message.DbException.get(DbException.java:205)
at org.h2.message.DbException.get(DbException.java:181)
at org.h2.command.ddl.AlterTableAlterColumn.update(AlterTableAlterColumn.java:114)
at org.h2.command.CommandContainer.update(CommandContainer.java:133)
at org.h2.command.Command.executeUpdate(Command.java:267)
at org.h2.jdbc.JdbcStatement.executeInternal(JdbcStatement.java:233)
at org.h2.jdbc.JdbcStatement.execute(JdbcStatement.java:205)
at com.zaxxer.hikari.pool.ProxyStatement.execute(ProxyStatement.java:95)
at com.zaxxer.hikari.pool.HikariProxyStatement.execute(HikariProxyStatement.java)
at org.flywaydb.core.internal.jdbc.JdbcTemplate.executeStatement(JdbcTemplate.java:235)
at org.flywaydb.core.internal.sqlscript.StandardSqlStatement.execute(StandardSqlStatement.java:42)
at org.flywaydb.core.internal.sqlscript.DefaultSqlScriptExecutor.executeStatement(DefaultSqlScriptExecutor.java:189)
at org.flywaydb.core.internal.sqlscript.DefaultSqlScriptExecutor.execute(DefaultSqlScriptExecutor.java:125)

40 minutes ago, jpowell8672 said:

Latest update broke hydra2

 

Removed, did fresh install with appdata hydra2 wiped, hydra2 loaded then did a restore backup from file & it's broke again same error: 

 

--------------------------------------------------------------------
SQL State : 42S02
Error Code : 42102
Message : Table "SEARCHRESULT" not found; SQL statement:
ALTER TABLE SEARCHRESULT
ADD indexerSearchEntity INTEGER [42102-199]
Location : migration/V1.21__LINK_SEARCHENTITY_TO_INDEXERSEARCHENTITY.sql (/app/hydra2/file:/app/hydra2/lib/core-2.7.1-exec.jar!/BOOT-INF/classes!/migration/V1.21__LINK_SEARCHENTITY_TO_INDEXERSEARCHENTITY.sql)
Line : 1
Statement : ALTER TABLE SEARCHRESULT
ADD indexerSearchEntity INTEGER

at org.flywaydb.core.internal.sqlscript.DefaultSqlScriptExecutor.handleException(DefaultSqlScriptExecutor.java:253)
at org.flywaydb.core.internal.sqlscript.DefaultSqlScriptExecutor.executeStatement(DefaultSqlScriptExecutor.java:202)
at org.flywaydb.core.internal.sqlscript.DefaultSqlScriptExecutor.execute(DefaultSqlScriptExecutor.java:125)
at org.flywaydb.core.internal.resolver.sql.SqlMigrationExecutor.execute(SqlMigrationExecutor.java:77)
at org.flywaydb.core.internal.command.DbMigrate.doMigrateGroup(DbMigrate.java:367)
at org.flywaydb.core.internal.command.DbMigrate.access$200(DbMigrate.java:54)
at org.flywaydb.core.internal.command.DbMigrate$3.call(DbMigrate.java:284)
at org.flywaydb.core.internal.jdbc.TransactionTemplate.execute(TransactionTemplate.java:74)
at org.flywaydb.core.internal.command.DbMigrate.applyMigrations(DbMigrate.java:281)
at org.flywaydb.core.internal.command.DbMigrate.migrateGroup(DbMigrate.java:246)
at org.flywaydb.core.internal.command.DbMigrate.access$100(DbMigrate.java:54)
at org.flywaydb.core.internal.command.DbMigrate$2.call(DbMigrate.java:164)
at org.flywaydb.core.internal.command.DbMigrate$2.call(DbMigrate.java:161)
at org.flywaydb.core.internal.database.base.Connection$1.call(Connection.java:147)
at org.flywaydb.core.internal.jdbc.TransactionTemplate.execute(TransactionTemplate.java:74)
Caused by: org.h2.jdbc.JdbcSQLSyntaxErrorException: Table "SEARCHRESULT" not found; SQL statement:
ALTER TABLE SEARCHRESULT
ADD indexerSearchEntity INTEGER [42102-199]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:451)
at org.h2.message.DbException.getJdbcSQLException(DbException.java:427)
at org.h2.message.DbException.get(DbException.java:205)
at org.h2.message.DbException.get(DbException.java:181)
at org.h2.command.ddl.AlterTableAlterColumn.update(AlterTableAlterColumn.java:114)
at org.h2.command.CommandContainer.update(CommandContainer.java:133)
at org.h2.command.Command.executeUpdate(Command.java:267)
at org.h2.jdbc.JdbcStatement.executeInternal(JdbcStatement.java:233)
at org.h2.jdbc.JdbcStatement.execute(JdbcStatement.java:205)
at com.zaxxer.hikari.pool.ProxyStatement.execute(ProxyStatement.java:95)
at com.zaxxer.hikari.pool.HikariProxyStatement.execute(HikariProxyStatement.java)
at org.flywaydb.core.internal.jdbc.JdbcTemplate.executeStatement(JdbcTemplate.java:235)
at org.flywaydb.core.internal.sqlscript.StandardSqlStatement.execute(StandardSqlStatement.java:42)
at org.flywaydb.core.internal.sqlscript.DefaultSqlScriptExecutor.executeStatement(DefaultSqlScriptExecutor.java:189)
at org.flywaydb.core.internal.sqlscript.DefaultSqlScriptExecutor.execute(DefaultSqlScriptExecutor.java:125)

There was another update, updated & still broken.

@jpowell8672 Checking the nzbhydrav2 change log shows this:

So it's an issue with the software itself, not the container. You'll need to find you last working backup and update that.

7 minutes ago, j0nnymoe said:

@jpowell8672 Checking the nzbhydrav2 change log shows this:

So it's an issue with the software itself, not the container. You'll need to find you last working backup and update that.

Yes, thank you it is back working.

I appear to have an issue with nzbhydra2 in that the nzbhydra.mv file grows out of control.

 

I've posted across on Reddit too, but hoping someone here might be about to help?

 

Here's the problem I'm having - Click me

 

Any ideas?

On 7/3/2019 at 9:18 PM, crazykidguy said:

I've this weird issue where season searches from within Sonarr will return results from my indexers but they don't get forwarded to SABnzbd. However everything works fine if I search each episode individually using the auto search function. 

 

Any idea why? The logs indicate there were results returned but it's just missing that last step of pushing it to SAB. 

 

The yellow logs are from the manual search.

 

 

So I think I've found the problem which is when a batch search doesn't return results for any particular search, it botches for some reason and nothing gets piped over to sab, even if there were legit hits before. 

Is it just me or did Unraid 6.8.2 break this?

It's broken for me.

23 hours ago, intoran said:

It's broken for me.

Same here.  This seems to happen to me every 2-4 weeks it will just randomly fail.  I think the DB keeps getting corrupted somehow and I have to delete the app folder, download a fresh image, restore from backup file i transfer into the new app folder, and then it works again for another 2-4 weeks before failing again.

This is broken for me as well.  The container seems to run for a few hours fine, then it thrashes in a boot loop taking tons of cpu with the constant restarting.  I believe it's an issue with the application itself.

On 3/21/2020 at 2:01 AM, growlith said:

This is broken for me as well.  The container seems to run for a few hours fine, then it thrashes in a boot loop taking tons of cpu with the constant restarting.  I believe it's an issue with the application itself.

I'm having the same issue

2020-04-15 13:44:16,559 INFO - Starting NZBHydra main process with command line: java -Xmx256M -DfromWrapper -XX:TieredStopAtLevel=1 -noverify -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/config/logs -Xlog:gc*:file=../../config/logs/gclog-2020-04-15_13-44-16.log::filecount=10,filesize=5000 -Dspring.output.ansi.enabled=ALWAYS -jar /app/hydra2/lib/core-2.17.5-exec.jar --nobrowser --datafolder /config in folder /app/hydra2
13:44:17.245 [main] DEBUG org.nzbhydra.config.ConfigReaderWriter - Using temporary file /config/nzbhydra.yml.bak
13:44:17.252 [main] ERROR org.nzbhydra.NzbHydra - An unexpected error occurred during startup

at org.nzbhydra.config.ConfigReaderWriter.validateExistingConfig(ConfigReaderWriter.java:164)
at org.nzbhydra.NzbHydra.startup(NzbHydra.java:147)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at org.springframework.boot.loader.MainMethodRunner.run(MainMethodRunner.java:48)
at org.springframework.boot.loader.Launcher.launch(Launcher.java:51)
Exception in thread "main" java.lang.reflect.InvocationTargetException
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.springframework.boot.loader.Launcher.launch(Launcher.java:87)
at org.springframework.boot.loader.JarLauncher.main(JarLauncher.java:52)
at org.nzbhydra.config.ConfigReaderWriter.validateExistingConfig(ConfigReaderWriter.java:164)
at org.nzbhydra.NzbHydra.startup(NzbHydra.java:147)
... 8 more
2020-04-15 13:44:17,264 ERROR - Main process shut down unexpectedly. If the wrapper was started in daemon mode you might not see the error output. Start Hydra manually with the same parameters in the same environment to see it

Logging wrapper output to /config/logs/wrapper.log
2020-04-15 13:44:17,528 WARNING - Didn't find XMX in YAML file, using default of 256

2020-04-15 13:44:17,565 INFO - Determined java version as '11' from version string 'openjdk version "11.0.6" 2020-01-14'

2020-04-15 13:44:17,565 INFO - Starting NZBHydra main process with command line: java -Xmx256M -DfromWrapper -XX:TieredStopAtLevel=1 -noverify -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/config/logs -Xlog:gc*:file=../../config/logs/gclog-2020-04-15_13-44-17.log::filecount=10,filesize=5000 -Dspring.output.ansi.enabled=ALWAYS -jar /app/hydra2/lib/core-2.17.5-exec.jar --nobrowser --datafolder /config in folder /app/hydra2
13:44:18.183 [main] DEBUG org.nzbhydra.config.ConfigReaderWriter - Using temporary file /config/nzbhydra.yml.bak
13:44:18.189 [main] ERROR org.nzbhydra.NzbHydra - An unexpected error occurred during startup

at org.nzbhydra.config.ConfigReaderWriter.validateExistingConfig(ConfigReaderWriter.java:164)
at org.nzbhydra.NzbHydra.startup(NzbHydra.java:147)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at org.springframework.boot.loader.MainMethodRunner.run(MainMethodRunner.java:48)
at org.springframework.boot.loader.Launcher.launch(Launcher.java:51)
Exception in thread "main" java.lang.reflect.InvocationTargetException
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.springframework.boot.loader.Launcher.launch(Launcher.java:87)
at org.springframework.boot.loader.JarLauncher.main(JarLauncher.java:52)
at org.nzbhydra.config.ConfigReaderWriter.validateExistingConfig(ConfigReaderWriter.java:164)
at org.nzbhydra.NzbHydra.startup(NzbHydra.java:147)
... 8 more
2020-04-15 13:44:18,200 ERROR - Main process shut down unexpectedly. If the wrapper was started in daemon mode you might not see the error output. Start Hydra manually with the same parameters in the same environment to see it

Logging wrapper output to /config/logs/wrapper.log
2020-04-15 13:44:18,522 WARNING - Didn't find XMX in YAML file, using default of 256

2020-04-15 13:44:18,558 INFO - Determined java version as '11' from version string 'openjdk version "11.0.6" 2020-01-14'

2020-04-15 13:44:18,559 INFO - Starting NZBHydra main process with command line: java -Xmx256M -DfromWrapper -XX:TieredStopAtLevel=1 -noverify -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/config/logs -Xlog:gc*:file=../../config/logs/gclog-2020-04-15_13-44-18.log::filecount=10,filesize=5000 -Dspring.output.ansi.enabled=ALWAYS -jar /app/hydra2/lib/core-2.17.5-exec.jar --nobrowser --datafolder /config in folder /app/hydra2
13:44:19.197 [main] DEBUG org.nzbhydra.config.ConfigReaderWriter - Using temporary file /config/nzbhydra.yml.bak
13:44:19.202 [main] ERROR org.nzbhydra.NzbHydra - An unexpected error occurred during startup

at org.nzbhydra.config.ConfigReaderWriter.validateExistingConfig(ConfigReaderWriter.java:164)
at org.nzbhydra.NzbHydra.startup(NzbHydra.java:147)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at org.springframework.boot.loader.MainMethodRunner.run(MainMethodRunner.java:48)
at org.springframework.boot.loader.Launcher.launch(Launcher.java:51)
Exception in thread "main" java.lang.reflect.InvocationTargetException
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.springframework.boot.loader.Launcher.launch(Launcher.java:87)
at org.springframework.boot.loader.JarLauncher.main(JarLauncher.java:52)
at org.nzbhydra.config.ConfigReaderWriter.validateExistingConfig(ConfigReaderWriter.java:164)
at org.nzbhydra.NzbHydra.startup(NzbHydra.java:147)
... 8 more
2020-04-15 13:44:19,213 ERROR - Main process shut down unexpectedly. If the wrapper was started in daemon mode you might not see the error output. Start Hydra manually with the same parameters in the same environment to see it

Logging wrapper output to /config/logs/wrapper.log
2020-04-15 13:44:19,523 WARNING - Didn't find XMX in YAML file, using default of 256

2020-04-15 13:44:19,560 INFO - Determined java version as '11' from version string 'openjdk version "11.0.6" 2020-01-14'

2020-04-15 13:44:19,561 INFO - Starting NZBHydra main process with command line: java -Xmx256M -DfromWrapper -XX:TieredStopAtLevel=1 -noverify -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/config/logs -Xlog:gc*:file=../../config/logs/gclog-2020-04-15_13-44-19.log::filecount=10,filesize=5000 -Dspring.output.ansi.enabled=ALWAYS -jar /app/hydra2/lib/core-2.17.5-exec.jar --nobrowser --datafolder /config in folder /app/hydra2
2020-04-15 13:44:19,692 INFO - Terminated by signal 15
2020-04-15 13:44:19,693 INFO - NZBHydra2 wrapper shutdown request. Terminating main process gracefully
[cont-finish.d] executing container finish scripts...
[cont-finish.d] done.
[s6-finish] waiting for services.
[s6-finish] sending all processes the TERM signal.
[s6-finish] sending all processes the KILL signal and exiting.

 

@linuxserver.io

 

Thread and app need to be updated to the new locations.

 

https://github.com/linuxserver/docker-nzbhydra2

https://hub.docker.com/r/linuxserver/nzbhydra2

There are 2 lsio hydra2 dockers on the app store.

• Older one points to linuxserver/hydra2
• New one points to linuxserver/nzbhydra2

What's the diff between them?

I'm using the old one, do I need to change to the new one?

2 hours ago, testdasi said:

• Older one points to linuxserver/hydra2
•  

Quote

THIS IMAGE IS DEPRECATED. We will continue releases with a new image under the correct name: linuxserver/nzbhydra2.

 

On 4/27/2020 at 9:25 PM, Squid said:

 

What would be the easiest way to migrate to the new image without losing any settings or data.  Is it as simple as deleting the image and renaming the app data folder to match the new name and then installing the app again?

Edited April 28, 20206 yr by danioj

11 hours ago, danioj said:

What would be the easiest way to migrate to the new image without losing any settings or data.  Is it as simple as deleting the image and renaming the app data folder to match the new name and then installing the app again?

This is what I did. I am sure there is a better way but these are the steps I took.

 

- Removed the current App (and image) from within the docker tab (this doesn't touch the folder with all the current app settings in the appdata folder).

- Installed the new App from within the Apps tab (CA) with the same network and path settings as the old App.

- Stopped the new App in the docker tab.

- Deleted all config files within the new folder created in appdata for the new App (no need to backup as they are fresh and can be pulled anytime).

- Copied all files from the old appdata folder to the new one.

- Started the App within the docker tab.

- Once confirmed that the App is working, deleted the old appdata folder.

 

All working fine.

Edited April 29, 20206 yr by danioj

What I did was similar to what danioj did, but I just created a backup under settings, then removed the docker, installed new image and restored the backup from settings in the new app.

I just edited the docker and changed the docker path from the old one to the new one: linuxserver/hydra2 to linuxserver/nzbhydra2

Then just save it, and it'll update the stuffs and be all set - don't need to copy/move/config anything!

 

Don't forget to go to advanced mode and edit the Docker Hub URL too! (from experience, ahem)

Edited May 3, 20206 yr by mbezzo

On 4/30/2020 at 10:48 AM, opiekeith said:

What I did was similar to what danioj did, but I just created a backup under settings, then removed the docker, installed new image and restored the backup from settings in the new app.

I did the same as opiekeith.  I went into the "older" docker and created a backup of my settings, then I stopped that docker.  I then installed the newer docker, went into its settings and restored the old settings from the backup I made.  I'm not sure if this was the best way, but its super easy and fast and everything is working perfectly