[Support] Linuxserver.io - NZBHydra v2


Recommended Posts

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.

Link to comment
  • 4 weeks later...
  • 4 weeks later...
  • 4 weeks later...

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.

 

 

Hydra2 Log.png

Link to comment
  • 3 months later...

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)

Link to comment
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.

Link to comment
  • 5 weeks later...
  • 3 weeks later...
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.

 

 

Hydra2 Log.png

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. 

Link to comment
  • 2 months later...
  • 2 weeks later...
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.

Link to comment
  • 1 month later...
  • 4 weeks later...
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.

 

Link to comment
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 by danioj
Link to comment
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 by danioj
Link to comment

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 by mbezzo
  • Like 1
Link to comment
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

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.